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ABSTRACT 
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This Final Report documents the development of a new framework and 
structure for shuttle era unmanned spacecraft projects and the develop- 
ment of a Commonality Evaluation Model. It also discusses the methodology 
developed for model utilization in performing cost trades and comparative 
evaluations for commonality studies. 

The new framework and structure are based upon functionally oriented 
rather than performance oriented elements. The model framework consists 
of categories of activities associated with the spacecraft system’s de- 
velopment process. The model structure describes the physical elements 
to be treated as separate identifiable entities. 

The Commonality Evaluation Model is a comparative cost model devel- 
oped specifically for making comparative evaluations of cost savings in 
unmanned interplanetary spacecraft programs and/or projects using varying 
approaches to and varying degrees of commonality. The unit of value is 
not the usual US dollar, but a Normalized Cost Unit (NCU). New cost es- 
timating relationships (CERs) for subsystem and program-level components 
have been calculated in NCUs. 

The methodology supports cost trades and comparative evaluation for 
commonality including hardware, software, and firmware elements as well 
as standard components. The methodology was constrained to the use of 
existing data. 
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The objective of this project, called Commonality Evaluation Model 
Development, was to perform further investigations concerning the existing 
JPL cost models as well as providing analysis and experience toward ex- 
tending the current JPL cost model to new areas in anticipation of poten- 
tial new management approaches and a new era of spacecraft launch asso- 
ciated with the shuttle. 

The contract effort was divided into three distinct sub-efforts, two 
of which were closely related and the third only loosely related. The 
first sub-effort was the development of a model framework and structure. 

The second sub-effort was the development of the Commonality Evaluation 
Model itself. The third was the quick development of four new cost es- 
timating relationships (CEPs). 

The first sub-effort developed a new framework and structure compat- 
ible with the requirement of a contemplated new unmanned spacecraft cost 
model. This framework and structure is required to support several new 
features including element definition at a sufficiently low level to 
separately identify the lov;est logical levels of commonality impact. The 
framework and structure is compatible with cost analysis of various modes 

I 

of project management and with standard components, distributed data sys- 
tems, and both hardware and software inheritance. The framework and 
structure were developed to meet broad scope requirements and then \vere 
recombined and compressed to accept existing CERs for the logic and method- 
ology of the Commonality Evaluation Model. 

The second sub-effort — development of the Commonality Evaluation Model - 
is closely related to the first. This sub-effort is both broader and nar- 
rower in scope than the title implies. It is somewhat narrower in that the 
model, as defined, is applicable only to unmanned, scientific interplanet- 
ary spacecraft and is constrained to utilize existing cost estimating re- 
lationships for the elements of a space project and therefore constrained 
to utilize a simpler framework and structure. It is broader, on the other 



hand, because the framev/ork and structure developed as a precursor to the 
logic and methodology had to be the new framework and structure developed 
in the first sub-effort in order to assure model compatibility with futured 
developments. 

During this effort, the CERs currently utilized by the JPL cost model 
were translated from "real" or "then" year dollars to 1975 dollars, nor- 
malized, and expressed in a cost called a Normalized Cost Unit (NCU) and 
replotted. In several, cases, previous errors were also corrected. Due 
to an insufficient experiential data base, NCU standard components CERs 
could not be developed at this time. However, provisions have been made 
to accomodate standard components; therefore, when sufficient data be- 
comes available, these CERs will be constructed and added. 

The third sub-effort, only loosly related to the first two, developed 
new cost estimating relationships for the following four new elements: 

0 Penetrators 

0 Surface Mobility Systems 

0 Solar Sails 

0 Ion Drives 
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II. INTRODUCTION 


As previously explained, the contractual effort encompassed three 
distinct areas of v-jork. This document covers on the two closely related 
efforts-, the development of the new framework and structure and the de- 
velopment of the Commonality Evaluation Model. The third effort is pub- 
lished separately in Planning Systems and Sciences Company Report 
P21-R-003. 

For convenience and logic of thought and presentation, the two 
different sub-efforts are contained in separate parts. Section III con- 
tains the technical discussion concerning the new framework and structure. 
Section III also contains its own conclusion and recommendations. 

In a like manner. Section IV contains the technical discussion con- 
cerning the Corinonality Evaluation Model as well as its associated con- 
clusions and recommendations. 

This report contains two appendices. The first contains the biblio- 
graphic data identifying the data base documents. The second contains a 
handbook for exercising the Commonality Evaluation Model. This handbook 
has also been published separately. 

Two items of note should be borne in mind by the reader. 

1. In order to assure the compatibility with future developments, 
the new framework and structure discussed in Section III was 
developed as a precursor to the Commonality Evaluation Model. 
Hov;ever, the framework actually used in the CEM and discussed 
in Section IV is a retrogression to a simpler set imposed by 
the constraints of using existing data. 

2. Primarily due to a lack of sufficient experiential data, CERs 
for standard components could not be developed at this time. 

The CEM, hov/ever, incorporates provisions for treating standard 
components. The CERs can be added when adequate data is avail- 
able for their development. 
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III. TECHNICAL DISCUSSION— NEW FRAMEWORK AND STRUCTURE 


A. O verview 

The rationale for the development of the new framework and structure 
is to determine if a functionally oriented rather than a performance 
oriented framework and structure could be developed for, and be compatible 
with, the requirements, for a new, shuttle era unmanned spacecraft cost 
model. The framework and structure v/ere required to support several new 
features, including element definition at a sufficiently low level to 
separately identify the lovjest logical levels of commonality impact. The 
framework and structure also had to be compatible with cost analysis of 
various modes of project management and with standard components, distri- 
buted data systems, and both hardware and software inheritance. 

The model framework consists of subdivisions of the model relating 
to categories of work effort or activities associated with the spacecraft 
system's development process. The framework was subsequently used to 
determine the hierachy of activities and phases of development to be 
considered separately when exercising the methodology. The model struc- 
ture was developed to describe the physical elements to be treated as 
.separate identifiable entities of the spacecraft and spacecraft support 
systems. PS&SC used the structure to identify the lowest level of com- 
monality that could be considered directly without a supplementary 
breakdown. 

Previously, most cost model structures have been oriented to the 
design characteristics of hardware such as weight, density and volume. 
These characteristics are sufficient so long as absolute governing con- 
straints exist that make it mandatory that hardware be designed to min- 
imize weight and volume. When these constraints are somewhat relaxed, 
as they are now with the advent of the Shuttle and increasing cost pres- 
sure, then the design characteristics no longer serve as reliable cost 
extimators. Therefore, performance parameters must then be turned to 
for the cost estimating relationships. 
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In order to provide niiaxii;:ufm utility and compatibility vn'th anticipated 
utilization and future developments, PS&SC developed the structure of the 
model after first identifying the "functional elements" of the spacecraft 
systems, A functionQl element is a hardware or software element of a 
space system that performs a specific job. It should be noted, however, 
that an element cannot and does not accomplish a mission objective without 
being combined with other functional elements. After identification, the 
functional elements were combined into composite functional elements, re- 
ferred to as major functions. 

As developed, the methodology is capable of performing comparisons of 
standard hardware components, standard software componenets, hardware in- 
heritance, software inheritance and the impact of operations commonality. 
However, in order to maintain a relationship with the current JPL practice, 
the composite functional elements are compatible with the structure of 
existing cost estimating relationships. 

B . M odel F rame vjork and Guidelines 

In order to describe the framework of the model, PS&SC collected un- 
manned spacecraft cost data applicable to development of the commonality 
evaluation cost model. During the period of data collection, a analysis 
of the constraints and applicability of all the data was undertaken. 

From this analysis, PS&SC characterized and defined the major develop- 
mental and operational activities of an unmanned spacecraft project. A 
synthesis of the characteristics was used to derive the framework of the 
model. The analysis and synthesis determined the functional elements that 
constitute the spacecraft system, supporting system, and mission elements. 

These functional elements provide definitions of major separable ac- 
tivities and sub-activities involved in the design, development, fabrication, 
testing, and operation of an unmanned spacecraft project. The primary goal 
was to select definitions for the framework descriptors that are generally 
accepted. 

This section describes the framework that was initially derived for 
the model and presents the general guidelines for model inputs. 
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The framework of the model is defined as consisting of seven distinct 
phases and/or activities of a project. Pach of these principal phases is 
subdivided into as many parts as necessary to account for differences in 
approach or purpose. 

The seven principal phases and the phase subdivisions are presented 
in Exhibit 1. In addition, a brief set of framework guidelines is pre- 
sented to help define the scope and activities making up each of the seven 
phases. Exhibits 2 through 8 present the guidelines for the subdivisions 
of each of the seven principal phases. 

C. Initial Model Structure and Technical Descriptors 

With these functional element characteristics end utilizing available 
CERs, PS&SC was able to develop a structure for the model. The structure 
of the model is defined as consisting of 13 subsystems and one system 
management element. The 13 subsystems are further divided into two or 
three major functions. The System Management element is also subdivided 
into two major functions. The purpose of the structure as defined is to 
allow the separation of functionally different hardwait e/fimware/software 
elements in order to enhance the ability of the model to handle the inter- 
element influences of commonality variations. Separation of the two major 
functions of the system management element achieves the same purpose. 

Descriptors were developed in a two-step process. The spacecraft 
system v;as first divided into its functional elements. After achieving 
satisfactory and workable functional element definitions and descriptors, 
the functional elements were recombined into composite functional elements 
compatible with existing CERs. Definitions and descriptors were subse- 
quently derived for the composite functional elements to provide a clearer 
understanding of the inputs required to adequately define portions of the 
systems. These descriptors include the hardware elements, software elements, 
system level elements, and mission additives. 

The subsystems (including Systems Management) and their related major 
functions are shown in Exhibit 9. Also presented in the exhibit are the 
technical descriptors that define the input paramenters that must be 
specified for each of the major functions or subsystems. 
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EXHIBIT 1 - MODEL FRAMEWORK AND GUIDBl 


aEOUlRtKEHTS OEFJNITIOH 


• Starts with the first efforts 
specifically oriented toward 
analysing the elef^ents of tne 
mission with the goal of fon=u< 
lating the rcgulrwents for the 
system* 

f All effort is conceptua] and/or 
analytical and directed toward 
detemining roquirenients* 

• Complete when system -level per- 
foiTancc requirements have been 
determined and specified. 


Hissipfl Analysis | 

1 System Analysis 1 

[Pcrfonnance Requirements' 


F II 


OESIGJI AUD OEVELOPHEHT 


« Starts with specific design 
effort oriented toward produc* 
ing subsystems that achieve 
system performance requirements. 

■ Effort is analytical and/or con> 
version of analytical results to 
hardware, finsware ahd/Or software 
eleroents. 

• Cofl^lete when all necessary ele- 
ments exist as proven prototypes 
or Item specifications capable of 
producing results required to 
achieve syst»o porfonnance re- 
quirements specified. 


Oesign 

Development 


F III 


PRDCUHEKEIIT AJiD MAltUfftaURlMG 


t Starts with preparation of 
procur^nt specifications for 
elements to be purchased. 

• Effort is conversion of proto- 
types and/or specifications to 
production hardware, fintware 
and/or software elements and 
interfaces. 

■ Cocplete when alt required subsys- 
temsi stand-alone elements and 
interface provisions have suc- 
cessfully passed acceptance 
tests that verify required 
performance 


Procurement 


Fabrication 


F IV 


[fiTECaATlOH 


■ Starts with physical asseo^^ly of 
elements 

• Effort is physical assertly and 
electronic integration of hard- 
ware, fireware and/or software 
subsystems and elements and 
Interim checkouts performed 

in process 

* Complete when all interim 
checkouts have been success- 
fully completed 



Assembly and Integration 


i 


Prototyping 
j Test 


Assembly 1 : j 

Acceptance Test 



Rework and guidelines space project 


F IV 


INTEGRATWfj 


tartJ with physical asseftibJy of 
Toaents 

ffcrt is physical asserily and 
tectnmic integration of hard- 
arc* rirrware and/or software 
ubsysteos and eleoents and 
nterfo chscuouts perfonaed 
n, process 

Delete whtn all Interin 
HeciLDUts have been success^* 
ully cocpieted 



Aise/i^ly and Integration j 


F V 


TEST W(D eVALJJATlW 


I Starts with full-scale func- 
tional test of Integrated 
systen 

a Effort is testing of total 
sysceta to verify perfarmajice 

• Complete when specified per- 
fornance verification ^and 
assorance testing have been 
successfully corrpleted 


System Test 


1 Design Verification 


[Jetnonstration 


Locisnes 

Starts with scheduling and ap- 
plication of support eleswnts 
of system 

Effort is Iciplcmentdtion of all 
elements of support required to 
achieve nission objectives 

Complete when mission has ended 
and system documentation has 
been completed 



F VII 


DPERATIOriS AHU MAI14TENANCE 


• Starts when system is in place 
at launch sitets) and ready for 
pre- launch check and/or support 
elements are in place and ready 
to be put into operation 

• Effort is operation and monitor- 
ing Of performance of the sys- 
tem and its elements 

• Complete when mtssion is termi- 
nated and results have been 

di strfbuted 


Launch Operations 
I Flight PperatiQfis 


Haintenance I 

I Data Processing & Hgt. 



Conceptual and analytical 

efforts performed to as- — 

sess the implications of ^ 

mission objectives and 

synthesize definitions 
of system-oriented per- b 

formance necessary 



SYSTEM ANALYSIS 


Conceptual and analytical 
efforts performed to 
formulate concepts of sys- 
tems, make tradeoffs and 
select approaches 

Determination of system- 
level performance require- 
ments for specific param- 
eters of selected system 
approach 


C. PERFORMANCE REQUIREMENTS 


d Development of system-level 
performance requirement 
specificati ons 

e Translation of specifica- 
tions to a level sufficient 
to allow design requirements 
to be derived for subsystems 
and interfaces 
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EXHIBIT 3 MODEL FRAMEWORK AND GUIDELINES 


DESIGN AND DEVELOPMENT 


Derivation of subsystem 
and lov/er element 
requi rements 

Conceptual and ana- 
lytical derivation of 
h a rdwa re/ f i rmwa re / 
software solutions to 
achieve the 
requirements 

Translation of the so- 
lutions to graphic and/ 
or written disclosures 


DEVELOPMENT 

Analytical and/or ex- 
perimental refinement 
of designs to prove 
concepts and perfect 
performance 

May involve breadboards, 
brassboards and/or 
simulation 


PROTOTYPING 

Producing functional 
models of the designs 
similar in physical 
characteristics to 
production units but 
often incorporating 
substitute materials 
and manufacturing 
methods 


Conducting testing 
of an experimental 
and exploratory 
nature to provide 
information neces- 
sary for the devel- 
opment process 




“^lanning'SyslemsTJnd Sciences 














EXHIBIT 4 - MODEL FRAMEWORK AJ^D GUIDELINES 


PROCUREMENT AND MANUFACTURING 


. PROCUREMENT 


Preparation of 

procurement 

specifications 

Carrying out of 
contracting or 
purchasing process 

Monitoring and ac- 
ceptance of pro- 
cured items 


B* FABRICATION/ 


'0 Conversion, using “pro- 
duction" methods and 
materials, of specifica- 
tions and/or prototypes 
to finished hardware, 
firmware and/or soft- 
ware elements and 
subassemblies 


ASSEMBLY 

Physical assembly and 
electronic intercon- 
nection of procured 
and/or fabricated items 
into subsystems and 
major stand-alone 
elements 


ACCEPTANCE TEST 

Testing of assembled 
subsystems, stand- 
alone elements and 
subassemblies to as- 
sure that they are 
capable of meeting 
their performance 
requirements 
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A. ASSEMBLY AND INTEGRATION 


® Physical assembly and elec- 
tronic integration of sub- 
systems and stand-alone ele- 
ments into a complete and 
integrated system capable of 
accomplishing the mission 
objectives 

0 Incorporates interim tests 
and checkouts necessary to 
confirm proper integration 










EXHIBIT 6 - MODEL FRAMEWORK AND GUIDELINES 


TEST AND EVALUATION 


SYSTEM TEST 


Full-scale functional 
test of the inte- 
grated system to as- 
certain that all 
functions perform as 
intended 


DESIGN VERIFICATION 

Performance of full- 
scale test to verify 
that integrated sys- 
tem meets performance 
specifications 


R&M DEMONSTRATION 


Conduct of tests to 
demonstrate that 
specified levels of 
reliability and/or 
maintainability have 
been met wi th stated 
degrees of confidence 
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A. LOGISTIC SUPPORT 


EXHIBIT 7 - MODEL FRAMEWORK AMO GUIDELINES 


LOGISTICS 


Planning* scheduling, 
arranging, controlling 
and monitoring the pro- 
visioning of supplies 
and support services 
requi red 

Movement of system 
and support equipment 
to site locations 


B* GROUND SUPPORT - 

EQUIPMENT 

e Planning and provision- 
ing of ground support 
equipment items required 
for system launch, oper- 
ations and maintenance 


C. SPARES 


Planning and provision- 
ing of spare systems 
and/or items that may 
be required to support 
the mission 


D, MAINTENANCE SUPPORT 


Planning, arranging 
and provisioning of 
maintenance services 


TRAINING 


Providing pre-launch 
maintenance services 


Planning, scheduling 
and providing re- 
quired training for 
operations and/or 
maintenance 


DOCUMENTATION 


Planning and provid- 
ing system documentation 
required for accomplish- 
ment of mission 
objectives 
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EXHIBIT 8 - MODEL FRAMEWORK AND GUIDELINES 


LAUNCH OPERATIONS 


Performance of pre- 
launch checkout and 
control of system 
during launch 
period 


F VII OPERATIONS AND MAINTENANCE 


B. FLIGHT OPERATIONS 


0 Control and monitoring 
of system functions 
during transit and 
encounter phases of 
mi ^sion 


C. MAINTENANCE 


0 Performance of pre- 
ventive and/or cor- 
rective maintenance 
actions that may be 
required during p re- 
launch, launch, transit 
and encounter phases of 
mission 


D. DATA PROCESSING AND 
MANAGEMENT 


e Processing and manage- 
ment of data and its 
distribution 








EXHIBIT 9 - MODEL STRUCTURE AND TECHNICAL DESCRIPTORS 


HARDWARE, FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 


S I. SYSTEMS MANAGEMENT 


Program Management 


Systems Integration 


Duration of total program (months) 

(a) Pre-launch (months) 

(b) Transit (months) 

(c) Encounters (months) 

Start date (month, yr) 

Number of S/C 

Number of major subsystem contractors 
(S/C, landers, probes, etc.) 

Number of separate experiments 

(a) Total data frames from each experiment 
(picture scans, IR scans, etc.) 

Sample returns to be attempted? 

Target bodies this mission— Primary 
mission objectives 

Contract mode (S) (inhouse, systems 
integrator, systems contractor, etc.) 
(Management) 

Level of configuration control (parts, 
assemblies, units, etc.) 


Number of major subassemblies per S/C 
Number of S/C 

Fraction of new subsystems per S/C 
Number of prior S/C programs similar to 
this one 

Number of launches 
Launch mode 

(a) Earth booster + staging 

(b) Shuttle + staging 

(c) Shuttle + S/C propulsion (sail, ion drive, 
etc. ) 

Number of new contractors this S/C project 
Number of experimenters 
Systems interface mode 
Redundancy mode (functional or block) 
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EXHIBIT 9 (Continued) 


HARDWARE, FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELtMENTS 


Active Data Acquisition 
(for each experiment) 


S II. SCIENCE 


B. Semi -Active 


Is this a primary 
experiment? 

Power required (kW) 

(a) Max 

(b) Min 

(c) Duty cycle 
Weight (mass- Kg) 

Data rates : 

(a) Production (bits/sec) 

(b) Storaqe--at experiment 
(bits) (Buffer) 

(c) Control commands (wds/ 
operations, total ops at 
one time) 

(d) Output frame size, bits; 
or other similar 
measure 

Does the experiment require 
a special position on the 
S/C (scan platform, min fov, 
etc. 

Number of prior interplan- 
etary missions with this 
type experiment (i.e., TV, 
etc. ) 

How much of the hardware of 
this experiment is new (%) 
to interplanetary S/C? 


As for A 


As for A 
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EXHIBIT 9 (Continued, 


HARDWARE, FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 


S II: SCIENCE (Continued) 


Active Data Acquisition 
(for each experiment) 


Volume of experiment (m'^) ; 

(a) Total i 

(b) Of each physically 
separate element 

Contracting mode (Grant, 

CPFF, etc.) for hardware 
Contracting mode for data ; 

reduction j 

(a) Is organization same 

as 9.? I 

Can this instrument be used 
beyond the primary mission? , 

Pointing requirements for 
this instrument (if not 
rigidly afixed to S/C 
structure) 

(a) Angular accuracy (az, el) 
{o±60 rad) 

(b) Slew rates (az, el (rad/ ; 
sec)) 

Is any part oF this experi- 
ment deployed after: (a 

one-time deployment) 

(a) Earth orbit insertion 

(b) Start of transit 

(c) Target orbit insertion 
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EXHIBIT 9 (Continued) 


HARDWARE, FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 


I 


I 

I 


S II. SCIENCE (Continued) 


j A. Active Data Acquisition 
I (for each experiment) 


Environmental limits on each 
part of experiment (max-mi n 
temp, radiation, etc.) 

(a) While non-active 

(b) While active 

Is a degraded mode of oper- 
ation possible? 

What percentage this experi- 
ment contributes to science 
objectives? 


1 

\ 

i 


i 

i 

i 

t 


i 

\ 


I 

i 


1 


1 

I 


I 


1 

i 


! I 

j 
! 

1 
i 

i 
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EXHIBIT 9 (Continued) 


HARDWARE, FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 


S III. PRIMARY STRUCTURE (Not designed to move relative to S/C fixed coord systems) 


A. Un pressurized (i.e., no internal pressure) 




,5. 

6 . 

.7. 

8 . 


Pressurized Structure (external structure sur- 
face has design pressure drop across surface— 
tanks, special atmosphere, ’etc.”) 


IL 

i2. 


.3. 


Weight (mass- Kg) 

What fraction of design similar to any prior- 
S/C structure of past engineering generation? 
new materials of construction? 

If yes; what, prior experience with this 
material, list similar structures of this 
material in last 3 years for earth orbit 
or interplanetary S/C 
new features in this design (i.e., shape; 
torques, stresses, etc., more than 20% of 
last design) 

Contractor-project relation for design/develop 
(in-house, etc. ) 

Contractor-project relation for fabrication 
Are new design methods being used? 

Unusual dynamic requirements (stress, high 
loads, etc.) 


Any 

(a) 


Any 


12 . 

i3. 

!4. 

is. 


'6. 

I 

i 

7. 

i8. 


Weight (mass- Kg) 

Pressure level (bars, psia, etc.) 

Volume (m3) 

Is this a new design? Or a new material of 
construction? 

Any new fabrication methods to be used? 

(a) Indicate prior use these methods for 
S/C uses 

Contractor-program relationship for Des/Dev & 
Fabrication 

Are new design methods being used? 

Unusual dynamic requirements (stress, high 
loads, etc.) 



EXHIBIT 9 (Continued) 


ro 

o 


i 

1 

1 HARDWARE, 

FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 

' T 

1 S IV. ENVIRONMENTAL REGULATION 

! ^ — — ^ 

i 

1 A. Acti ve 

1 

■ r ■ ■ 1 - ' 

i 

j B. Passive (Point, etc.) 



■'I. 



Controlled parameter— temp, radiation, EMI, |l. 
etc. • ; 

Weight of control device(s) (kgms-niass) \Z. 

(a) Sensor(s) I 

(b) Effector! s) |3. 

Power required (KW) i 

(a) Max-pwr . 

(b) Duty cycle i 

(c) Min-pwr 1 

Prior history of similar devices i 

(a) % common this design and last design in ' 

past engineering generation I 

(b) % cotraion this fabrication and last fabri- | 

cation in past engineering generation ! 

Any special requirements for location on S/C | 
(radiators, etc.) 

Any special tests or equipment needed for S/C | 
integration? (new methods) - ' 


Weight not otherwise accounted for (as struc- ; 
ture, etc.) 

Prior use of this method in similar missions— ■ 

% common to prior use 

Special fabrication methods or prelaunch | 

handling required? 

1 

j 


I 



I 
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EXHIBIT 9 (Continued) 


HARDWARE, FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 


S V. SECONDARY STRUCTURE 


A. Fixed 


B. Movable 


II. 

. 2 . 

3. 


14. 

15. 


Weight (mass-kgins) jl. 

Area (m2 if "flat plate") j 

Any special materials or handling constraints-- |2. 
what? i 

(a) If new material, designs, or fab tech- j 

nique— what is history of use in space? j 

Function on S/C |3. 

Shape and form j4. 


|5- 

i6. 

i 

\ 7 . 

| 8 . 

\ 9 . 


Function (sail, solar panel, arm, etc.) 
(scan platform) 

Number of motions 

(a) One deployment 

(b) Intermittent extension/retraction/slew 

(c) Continuous 
Weight (mass, kgm) 

How moved--gas/hydraul i c/el ectri cal 
(a) Pov/er required 
Max 
Min 

Duty cycle 
Number and type of 
veloci ty/etc. 

Number and size of 
wds, vocab) 

On-board or earth-generated commands 
New materials or methods in fab? 

Fraction of this design/devel/job used 
prior S/C 


control sensors — position/ 
commands to controller (bits. 


in 












jl. Thrust (lbs or newtons) 

■|2-, Fuel/oxidizer-~or monopropellant? 

;3. Purpose— injection, etc. 

'4. Fraction of this design used in prior S/C 
’ project 

15. Prior fabrication experience this type, this 
; . class thrusters 

|6. Proof test models fabricated and tested 
Power to start — kW-sec 
|8, Total AV propul sor(s) 

I 

i 

i 

i 

1 

I 

I 

I 


jl. Type— ion, chemical, other 
|2. Elect power required - (kW) 
i Max 

I Min 

J Continuous 

Is. Weight of working fluid if ion drive 
j4. Thrust (chemical) (lbs or newtons) 

:5. Number of thruster elements if ion drive 

'6. Fraction of design new this time? 

j7. Any new materials or fuels this design (for 

! S/C projects)? 

j8. Variable thrust? 

, (a) Ion drive matrix 

' (b) Throttleable chem 

|9. Duration of chemical burn — total 
I Number of restarts (if any limit) 

10. New design methods used on this item 
■11. Total AV propul sors 
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EXHIBIT 9 (Continued) 




1 — 

1 

! HARDWARE , 

i 

FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 

\ 

1 ... S _VII.._P0WER . ■ 

1 ■ - . ■ .1 " 

f 

1 A. Generated 

1 B. Stored 

1 



( 

I 

t 


I 


[3. 

1 

j 

i 

I 


I 


5. 


6 . 


Method =(solar cells, RTG, other) 

If solar cells: 

(a) Array size (m^) and kW/Kg of array 
at lAU 

(b) Total power (lAU) of array (kW elect) 

(c) Are concentrators used? 

(d) Total area of array (Weight of array if 
concentrators used) 

(NB: Tilting, furling, etc., under 

movable structure) 

(e) Any new materials this S/C power array? 

If RTG's: 

(a) Power per unit RTG (Th-kW) 

(b) Number of RTG's/SC 

(c) Total electrical power at start of mission 
end of primary mission, max useable life 
of RTG this mission (yrs, pwr load) 

(d) New materials this design 
Number of different services: 

(a) Supply frequencies (DC, 400 AC, etc.) 

(10 , 30 , etc.) 

(b) Voltages (24, 440, etc.) 

(c) Inverters 

Weight of conditioning and cabling (Kg) for 
S/C 

(All of above for each element of a separable 
S/C) 

Prior design/job history of similar equip on 
S/C 


U. 

i 

i 

. 2 . 
! 3. 
l4. 




I 

! 

! 


Weight of cells (mass Kg all up, except . 
structure) ■ i 
Type of cells (NiCd, etc.) 

Capacity of battery (each, if more than one) ; 
Prior S/C use of this kind of battery and cell : 
Number of independent batteries i 


i 
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EXHIBIT 9 Continued) 


HARDWARE, FIRMWARE, SOFTWARE Ai\D SYSTEM MANAGEMENT ELEMENTS 


S VIII. ATTITUDE REGULATION 


Real Time (Earth 


Real Time (Sensor' 


Pre-Proarammed 


On-board sensors j 

(a) Star/sun trackers i 

(b) Horizon sensor : 

(c) Stable platform i 

(d) Required accuracy of the 

above ' 

Effectors j 

(a) Momentum wheels 

(b) Cold gas jets—stored gas; 

(c) Photons momentum exchange! 

(d) ion drive elements ' 

(e) S/C spin on one or two j 

axes ■ 

Weight of systems not other- \ 

wise accounted for (mass- i 

Kg) I 

Data words and rate to effect ; 

control 1 

Number of axes controlled 1 

Prior design/development/ 
fabrication experience with i 

devices ! 

Power required (kW) 

(a) Duty cycle j 

(b) Max i 


1.-7. Same as A |] 

8. On-board computer capacity and; 

access required; interrupt ! 
pri ori ty j 

9. New design/dev/fab this sys- ! 

tern this S/C I 


I.-8. Same as B 
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EXHIBIT 9 (Continued) 


HARDWARE, FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 


1 

s 

IX. GUIDANCE (On-board & terrestrial (other external) facilities) 

(Does not include S/C computer) 


1 

A. Real Time (Earth) | 

1 ^ 

B. Real Time (Sensor) j 

C. Pre-Programmed 

1. 

1 

Up- link data words 1 

r 

1. 

Sensor mode for guidance (may ' 

See A & B , computer system 
capacity dedicated to this 
function 

1 

f 

(a) Max rate j 

i 

i 

1 

be same as for VIII) and ac- { 
curacy of sensing I 

l2. 

i 

1 

Down link status reporting 
words required before a i 

2. 

Programming of on-board com- j 
puter--and words required j 


i 

|3. 

maneuver 

On-board decoding and control 
of effectors (computer 

3. 

Down-link words required to ; 
report proposed maneuver and ' 
intended commands to effectors! 


! 

i 

function) 1 

Terrestrial DSN time per ma- 
neuver-planned worst case, 

4. 

On-board computer capacity for' 
calculations and control ! 
(cf = X, XI, XII, XIII) ! 

i 

i 

1 

:5. 

planned expected case 
Terrestrial (SFOF) computer 1 

‘5. 

1 

t 

Any otherwise unaccounted for i 
weight (mass-kgm) 1 

i 


j time per maneuver--data re- 
I duction plus maneuver calcu- 
j lation and check 
6. Total number of maneuvers 
contemplated (interacts with 
propulsion here) and A\l ex- 
pected and maximum for 
guidance 

!?. Any otherwise unaccounted for 
weight (mass- Kg) 
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EXHIBIT 9 (Continued) 


: 

hardwarl, firmware, software and system management elements 

S X. COMMAND AND CONTROL 

— 
1 . A* Real Time 


i 

;l. Up-link capacity for C&C (cf: XI) 

12. Computer capacity for C&C (cf; XIII) 

|3. System response time to effect commands— 
seconds/hrs/days 

1 

l 

1 

F 

i 
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EXHIBIT 9 (Continued) 


HARDWARE, FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 


COMMUNICATIONS (Radio, laser, etc.) 


A. Transmitters 


B. Antennae 


C. Receivers 


Number of different trans- 
mi tters 

Power (max) of each Xmitter 
(total elect requirement) 
Frequency (carrier or center) 
of each Xmitter 
Weight of all Xmi tters & asso- 
ciated cables, feeds, etc. 

(Kg mass) 

Modulation of each Xmitter 
(AM, FM, PM, etc.) 

Prior S/C usage of each Des/ 
Dev/Fabrication for this S/C 
Band width each Xmitter 


Number of antennae 

Size of each (m2 if parabolic] 

(m-length for omni's) 

Weight of each antenna (mass 
kgms) 

Are any new construction tech- 
niques or new design require- 
ments contemplated? What are 
they? 

Antenna surface accuracy 
Antenna pointing accuracy 
required 


Number of receivers 

Power required for operations 

(max, standby) 

Weight of receiver system in- 
cluding feeds 

Any new design requirements 
since last S/C? 

Any new technology since 
last S/C? 

Frequencies and modes of each 
receiver 

Any switches activated by S/C? 
Where and what is switched? 
Redundancy mode 
Sensitivity in receiver 
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EXHIBIT 9 (Continued) 


HARDWARE, FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 


S XII, DATA HANDLING 


A. On Board 


Storage volume (max) (in bits or words) 
Memory form— tape, array, etc. 

Format data before or after store? 

Code before or after store (input or at 
Xmitter time) 

Weight of non -computer memory (Kg mass) 
Power requirements (KW) 

Max 

Min 

Standby 

Central or local controller on mass memory 

Read in/read out rates 

Memory volitility protection device 



Number of experiments on S/C 
Down-link data rate— raw and decoded 
Hours of data expected (reels of tape, etc.) 
Decode and distribution time (hours/Mbit) 
On-site initial data processing— kind, amount 
Temporary storage capacity preprocessing and 
post local processing 

Security provisions for data and facility 
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EXHIBIT 9 (Continued) 


HARDWARE, FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 


S XIII. COMPUTING (S/C) 


A. Control 


B. Distributed 


Weight — (mass Kg) 

Prior requirements (kW) 

(a) Max 

(b) Standby 

CPU description (functions, cycle time, etc.) 
Main memory volume 
Auxiliary memory volume 
Word size 

A-0, D-A converter 
Power requi red 

Programming langjage--is there an assembler, 
compiler? 

Is the language new, fraction used before? 

Is this a new computer — how much is common to 
prior S/C? 


1. Number of processors 
\Z. Auxiliary bulk memory size- 
:3. Total weight of computing system not otherwise 
accounted for 
;4. Power required (H'W) 

5. Is there a compiler and/or an assembler for the 

! processors? 

6. How much of system is new this time? How much 

! is common to prior S/C? 

.7. Number of A-0, D-A converters in system (if 
■ any) 

;8. Is there a system controller processor, or is 

the supervisor distributed? 

9. Word size 
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EXHIBIT 9 (Continued) 


HARDWARE, FIRMWARE, SOFTWARE AND SYSTEM MANAGEMENT ELEMENTS 


S XIV. STATUS MONITORING 


A. Active 


8. Passive 


Weight of monitors, cables, and converters 
Power required to monitor (kW) 

Data word format for status messages 
Frequency of monitor output(s) 

Is there command sensing? 

Does monitor function affect on-board 
controllers? 

Prior use of this design on S/C, how much is 
new? 

Is there command interrogation of status from 
Mission ControHer(s)? 


I As in A. (1-8) 
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The descriptors are shown at the major function level wherever possible. 
In those instances where available and usable Cost-Estimating Relationships 
(CERs) iriiposed restrictions at the subsystem level, the descriptors are 
not shown for the missing majc,' functions, 

D . Framework an d St r u cture Maturity 

During the course of the analysis, the new fra)iiework and structure 
concept matured and grew. Utilizing the functional element characteristics 
presented and the structure developed in Section III B and C, and the 
availab^’e CERs, the initial integrated framework and structure is as shown 
in Exhibit 10. 

Refinement of the framework and structure continued during the sub- 
sequent project period. Through a process of synthesis and analyses of 
technical interplay with OPE, adjustments were made in the structure. 

During the perfoniiance of the project, the structure was also changed to 
incorporate the System Management elements which were reomved from the 
definition of the framework. This change is shown in Exhibit 11. 

As additional development effort was expended, the final refinement 
was made when the framiework and structure were changed further by intro- 
ducing a third dimension. In creating the three dimensional aspect, man- 
ageifient elements {both system and program) were removed from the existing 

I 

two diiiionsi onal presentation, and established as a second structure din'.en- 
sion of system level elements. The three dimensional framework and struc- 
ture is illustrated in Exhibit 12. Although the three dimensional approach 
makes the framework and structure appear to be inore complex, this approach 
does facilate adequate treatment of the variations in management approach. 

In the three dimensional aspect, the framework, as one dim,ension 
(Exhibit 12), defines those phases and activities of a project which con- 
stitute essentially separate entities from tv;o standpoints: first, the 

standpoint of cost accumulation and second from the standpoint of impact 
due to differing project philosophies. 

The remaining two dimensions consist of two structures, 1 and II. 
Structure I defines the hardware elements of the system and the software 


STRUCTURE 





STRUCTURE 


EXHIBIT 11 - MODIFIED INITIAL INTEGRATED FRAMEWORK AND STRUCTURE 

FRAMEWORK 



DESIGN 

PROCUREMENT 


TEST 


OPERATIONS 

REQUIREMENTS 

& 

& 

INTEGRATION 

& 

LOGISTICS 

& 

1 DEFINITION 

DEVELOPMENT 

MANUFACTURING 

1 

1 

EVALUATION 


MAINTENANCE 


SYSTEMS MANAGEMENT 

I SCIENCE 

[ PRIMARY STRUCTURE 

j ENVIRONMENTAL REGULATION 
j SECONDARY STRUCTURE 

I PROPULSION 

I POWER 

I ATTITUDE REGULATION 

I GUIDANCE 

I COMMAND & CONTROL 

COMMUNICATIONS 

" 

DATA HANDLING 

COMPUTING 

STATUS MONITORING 
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EXHIBIT 12 - FINAL FRAMEWORK AND STRUCTURE: THREE DIMENSIONAL 


uj „ SYSTEM MANAGEMENT 
^ PROGRAM MANAGEMENT 


FRAMEWORK 


RQMTS /DESIGN / PROCUR 
DEF /& DEVEL / & MFG 


/ TEST 
INTEGR / & EVAL 


f / OPS & 

LOGISTICS/ MAINT 


SCIENCE 


f PRIMARY STRUCTURE 
SECONDARY STRUCTURE 


ENVIRONMENTAL REGULATION 


PROPULSION 

if — — 

POWER 

/ ATTITUDE REGULATION 


GUIDANCE 


/ COMMAND & CONTROL 
/ COMMUNICATIONS 

/ DATA HANDLING 

COMPUTING 


STATUS MONITORING 


U[M/ 
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elements related directly to the hardware elements. These elements are 
in turn defined by a three-level hierarchy similar to Exhibit 9, that 
starts at the subsystem level, proceeds to the major function level and 
then to the functional element level. These three levels of definition 
proceed from functionally separate elements that are consistent with our 
understanding of "subsystems" downward to functional elements. These 
functional elements are closely related to the performance parameters that 
determine the capabilities of the space system. This capability to re- 
late to performance parameters is absolutely necessary in a new cost model. 

Structure II defines the system management elements that cut across 
all hardware elements and all activities of the project. 

E. Conclusions and Recommendation 

1. Conclusions 

0 The framework and structure developed constitutes an 

ideal starting point for the development of a new space 
project cost model. 

0 Adequate analysis has been performed to demonstrate that 
the desired framework and structure could be developed. 
Initial analysis also shows that adequate CERs and "raw" 
cost data exist to, proceed with model development with 
reduced risk. 

2. Recommendation 

0 The framework and structure developed during this project 
should be used as the point of departure for a totally 
new unmanned space project cost model. A cost model built 
on this foundation would overcome many of the difficulties 
encountered in the existing models. 
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IV. TECHNICAL DISCUSSION— COMMONALITY EVALUATION MODEL 


A. Overview 

Utilizing concise mathematical methdology, the Coiiimonality Evalua- 
tion Model (CEM) generates relative cost comparisons between program 
and/or project commonality alternatives incorporating different levels 
and/or different applications of commonaltiy. The intermediate model 
results provide relative, pre-launched phase costs of the alternatives, 
and the final model results are comparative savings attributable to 
commonal ity. 

The model is optimized specifically for the purpose of making com- 
parative evaluations of potential cost savings in the construction of 
spacecraft for unmanned interplanetary scientific missions. As imple- 
mented, these cost savings accrue through the use of components or entire 
subsystems commont to more than one program or to more spacecraft than 
would normally be assembled for a single interplanetary project. Conse- 
quently, the Model explicitly incorporates the effects of learning on 
two different but related aspects; first, on the production processes 
of the subsystems and second on the system or project-level costs of such 
spaqecraft programs. With these two features, the CEM departs from the 
existing cost estimating models for unmanned spacecraft. 

A smaller difference from mast models of this type is in the treat- 
ment of technological inheritance. In the Commonality Evaluation Model, 
an estimate of the fraction of each subsystem which is new, either in 
materials or technology-design is made. Empirically derived functions 
relate the potential savings in design and development and type approval 
testing for that part which is not new. 

' In addition to these hardware and performance related features, the 
unit of value is not the usual US dollar, but a specially defined unit 
of account, the Normalized Cost Unit (NCU). The model does not estimate 
the realized costs, in current value money, of the spacecraft construc- 
tion portion of an interplanetary scientific mission. No provision is 
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made for inflation correction. Therefore, the model results can best be 
throught of as providing relative cost at the time of construction, inde- 
pendent of the value of the dollar at that time. 

The development of first the framework and structure and then the 
model logic and methodology v/as accomplished through a theoretical analy- 
sis and application of experimental data collected from past space proj- 
ects, During the CEM development effort, numerous variables were inves- 
tigated including most of the performance and design parameters of un- 
manned space systems. In addition, the relationship of project costs 
to variations in testing requirements, operational approaches, hardware 
maturity and weight and volume constraints were also investigated. An 
additional area of variables investigated was the contribution of the 
learning factor to reducing the cost of both manufacturing and engineer- 
ing tasks. 

1. Constraints 

The Commonality Evaluation Model (CEM) had, of necessity, to be 
derived under certain constraints; primarily the resources available and 
the time schedule which had to be met. As a result of the resources con- 
straint, only existing .data could be employed in this effort; no new data 
could be collected or analyzed. After a thorough search of the litera- 
ture and the accumulation of an extensive collection of possibly rele- 
vant reports, the amount of useful data and prior modeling experience 
which was relevant to this effort was determined. With some small later 
additions It was found that there was one report with apparently reliable 
cost information for a number of missions of the type of concern here 
and there were two, related, cost models which could be used to hlep in 
the analysis of the cost data. 

In a conventional sense, spacecraft programs consist of five well- 
defined phases. The Commonality Evaluation Model was specifically de- 
veloped to assess commonality during only the pre-launch phases of un- 
manned space programs. Emphasis upon commonality only during spacecraft 
production is due primarily to a very weak cost dependence between that 
phase and the other phases of pre-program, launch and cruise operations, 
encounter, and post encounter. 


37 


Planning Systems and Sciences 

Emphasis has been placed upon a particular type of spacecraft which 
is applicable to the JPL mission; i.e., the three-axis stabilized space- 
craft. Utilizing the necessary CERs for the specialized functions and 
interactions involved, the CEM will accommodate any type of spacecraft. 

2. CEM Framev.'ork and Structure 

Due to the constraint of working with existing CER's as well as 
changes in the accounting baseline, it was necessary to retreat from the 
newly developed framework and structure and utilize the more conventional 
framework and structure of the current JPL Cost Model . Hov/ever, because 
we are only working with the spacecraft development/production phase, 
some modification to that structure was permitted. 

For purposes of the CEM, a standardized subsystem set was defined. 
This list is shown in Table 1. It must be recognized that it is at the 
subsystem level that a very significant portion of the costs of a space- 
craft program are incurred. Therefore, it is at this level that the po- 
tential for savings by the use of subsystems common to more than one pro- 
gram or containing a large fraction of coniinon subassemblies exists. 
Moreover, it is at the subsystem level that the greatest effects of tech- 
nological maturity are observed. 

In all programs of the type considered here, the subsystems acqui- 
sition has bron the single largest cost. Other non-subsystem costs in- 
curred. Since these are attributable to system level activities, the 
model attributes them to Program Component Costs. These cost categories 
are shov.n and defined in Table 2. 

3 . Commonality Defi n ition 

A spacecraft is composed of a number of functional subsystems. 
These functional subsystems are then integrated into the finished flight 
article or spacecraft. Commonality is obtained when major components 
of the spacecraft subsystems are cominon to cHher a series of programs 
or when a program with a significant number of spacecraft will have one 
or more components common to each of the spacecraft. 



planning Systcrns and Sciences 

Table 1 

COMMONALITY EVALUATION MODEL SUBSYSTEMS 


1. Structure I (fixed, immovable mechanical structure and supporting 
members of the spacecraft) 

2. Structure II (mechanical devices, hinges, springs, dampers, rotating 
joints, pin-pullers, etc.) 

3. Structure III (pressurized structure, typically cold gas vessels and 
rocket fuel and oxidizer tankage) 

4. Propulsion (specify kind, may be ion-drive, chemical rockets, or 
solar sails) 

5. Guidance (includes star trackers, sun sensors, and the Central Com- 
puter and Sequencer, if any, in the spacecraft) 

6. Attitude Control (includes the roll, pitch, and yaw sensors, the 
means for rotating the spacecraft about its axes, and any expand- 
able stores associated with such control) 

7. Communications (includes the on-board radio system from the modulat- 
ors to the antennae for X-mitters and the antennae to the demodulat- 
ors for the receivers; it will include any special power condition- 
ing which is used by the radios exclusively) 

8. Data Handling (includes all data collection and on-board data stor- 
age devices and all encoding and pre-modulation modification of 
the on-board generated data stream) 

9. Power (includes the power generation, solar cell or other, and all 
conditioning for the spacecraft power service, but not any dedicated 
power conditioning associated with a particular instrument or 
subsystem) 

10. 'Science (includes all scientific instruments on board the spacecraft; 
does not include supporting structure or scan platforms unless a 
functional part of the instrument, not just supports or pointing 
aids) 
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Table 2 

Coinmonallty Evaluation Model Program-Level Coinponents 


Program Management (all the costs of administering the spacecraft 
program which are program specific) 

Systems Analysis and Systems Engineering (the costs usually paid 
for the systems level technical effort in design and in such areas 
as the engineering part of systems integration) 

Systems Test (the costs of all systems level testing of the as- 
sembled spacecraft, but not of any single subsystem or component) 

Quality Assurance and Reliability (the costs of all the system 
level QA&R effort, but, again, not that of any component) 

Assembly and Integration (the costs of assembling the subsystem 
and integrating them into a functioning spacecraft, exclusive oT 
testing) 

Operational Support Equipment (the necessary test and checkout 
equipment for the spacecraft at the system level; subsystem OSE 
is part of the cost of subsystem hardware) 




In either case, it is expected that the amor{'i^za^'?o^t^^Vf^?fie^co^ 
of design, development, testing, and manufacture can be an effective 
means of cost savings. Clearly, there will be savings at the level of 
the individual subsystem from quantity production, each spacecraft being 
then charged only the costs of the (amortized) hardware plus the flight 
acceptance testing. Even further savings can be anticipated at the sys- 
tems level of the programs. 

Savings are accrued due to more expeditious assembly and integration 
of each spacecraft primarily through familiarity with the subsystem com- 
ponents at assembly time. That is, if fewer problems arise during inte- 
gration, less time need be allocated for that step. Other program com- 
ponents will also show cost savings through the reduction in systems test- 
ing required, the reduction in reliability problems, and in the shorter 
time it will take to conduct the spacecraft pre-launch part of the pro- 
gram. These improvements do not necessarily come about because the in- 
dividuals vjorking on the programs have gained hands-on experience with 
the common elements, although this may be the case. Of much greater im- 
portance is the fact that, since the elements are programmed to be pro- 
duced and used more than one time at the outset, documentation is pro- 
duced, corrected, and updated. Consequently, errors are found and cor- 
rected and interfaces are better defined, described, and delineated. 

These factors, error correction and documented experience, allow the 
repetitive experience to be transferred and applied each time the corrsaon 
components are used. 


4 . Inheritance an d Novelty Fract ion 

While commonality considers the transference of entire subsys- 
tems from one spacecraft program or project to another, cost reductions 
can also be affected by using basically tried and proven methods; i.e., 
indirect rather than direct transference. 

For example, a particular device or design is ’’technically mature" 
when it is very similar to a recent predecessor in both design and mater- 
ials of construction. As a design group becomes more and more familiar 
with its task and as the ways of doing that task are explored, one method 
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is finally decided upon and used several times in succession. With the 
requirement to design the next number in the sequence, the design group 
will proceed to implement the design with the familiar approach at a 
considerably savings in time. The design group will not be faced with 
problems which require alternatives to be tried, such as the materials 
of construction and methods of assembly. In addition to what to do, they 
will have learned what not to do. Thus, savings in the pre-production 
stage of prototype production and testing are achieved. 

In the CEM, the degree of technological maturity is measured in 
terms of the' "novelty fraction" (Np) of the subsystem (Table 3). A 
value of unity (1.0) indicates an entirely new design and/or new mater- 
ials for the intended application. This does not imply that the tech- 
nology or design is being done for the first time ever. A "novelty frac- 
tion" of 0.0 indicates a tried design and previously used materials being 
utilized by a new spacecraft program or project. 

The complement of the "novelty fraction" in a subsystem is the 
"heredity." Previous JPL cost models utilize the concept of design 
inheritance. Inheritance is usually the most obvious feature and recog- 
nizable at a glance. However, inheritance is not the feature which causes 
increased cost to the design and development. Neither novelty nor inher- 
itance have a measurable impac^t on first unit production cost. 

B . T he Commonality Evaluation Model 

This section presents the Commonality Evaluation Model (CEM). In 
simplist terms, the CEM consists of three items. The first and most im- 
portant is the generalized mathematical model itself. The other two are 
supporting but integral data--the CERs (Exhibits 13 through 28) and the 
Tables of Factors (Tables 3 through 8) for various model parameters. 

1 • Ma themat ical Model 

In this section, the Commonality Evaluation Model (CEM) is de- 
lineated in general terms. Details of the actual computational procedure 
are contained in the Handbook (Appendix B). 


Subsystem Design & Development Cost-NCU/lb 








Subsystem Design i Development Cost-NCU/lb 



Subsystem Hardware Cost-NCU/lb 




Subsystem Oes 
















EXHIBIT 16* SUBSYSTEM CER: PROPULSION 


D&D 

Thrust NCU/lb-Th 


Hydrazine 


50 lbs 


1.711 


Monomethyl /hypazi ne 
+ Nitrogen Tetroxide 


300 lbs 1.859 


Use - Comments 


HW Cost 
NCU/lb-Th 

.0309 

.0488 


Flyby-midcourse — single chamber 
only 


Orbital injection and midcourse 
corrections — single chamber only 
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EXHIBIT 17. SUBSYSTEM CER: GUIDANCE 


Design and Development: Flyby 


Hardware 


^l^i^^De^gn and Development: Orbiter 


Subsystem Weight-Lbs 






Subsystem Design & Development Cost-NCU/lb 



Subsystem Hardware Cost-NCU/lb 



















EXHIBIT 20. SUBSYSTEM CER: DATA HANDLING 



ibsystem 
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EXHIBIT 21. SUBSYSTEM CER: ELECTRIC POWER (SOLAR ARRAY SOURCE) 


Design and Development 
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EXHIBIT 22. SUBSYSTEM CER: SCIENCE (SCAN PLATFORM & STRUCTURE MOUNTED) 


Hardware 


Design and Development 


Subsystem Weight-Lbs 














Management Cost-NCU 
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The inputs to the model are as follows: 

1. The subsystems paramters of weight, power, thrust (P ) 

2. The Novelty Fraction for each subsystem (Np ) 

3. The number of Flight Articles (spacecraft to^be assembled) 

(Npa) 

4. The total number of uni^s produced (Np) 

5. The total number of each pair of subsystems to be installed 

in three or more spacecraft, for all programs (P..) 

In the model there are M subsystems. For each subsystem, the total 
subsystem cost is composed of a Design, Development, and Type Approval 
Testing contribution (C^) and a Hardware plus Flight Approval Testing 
contribution (Cj^) . Thus, for the i th subsystem. 


c 


di 





) + t 






( 1 ) 


where ^di (P^^_ > *^p.) is the functional relation betv/een the novelty, 
the parameter, and the NCU cost, for Design & Development and where 
t^. (P 55 . > Np.) is the corresponding relation for Typo Approval Testing. 
For the hardware there exists the relationship 


c 


hi 






( 2 ) 


where gd(P^_.) relates the subsystem parameter to the unit hardware cost, 

I 5S -j 

tp^. (Pgg.) relates the Flight Approval Testing cost to the parameter, and 
Np is the number of type approval tests. 

If the subsystem is a common one, i.e., is to be acquired from a pro- 
duction quantity, then the approach is somewhat similar. For each conunon 
subsystem all the acquisition NCU costs are put into ^^(Pgg ) by the fol- 
lowing relationship: ^ 


<”ss,> = fdi ^ "TSiCss.) " • 


(3) 


where F;(Nn.) is the learning factor and represents the fraction of the 
first unit cost which is the average unit cost of the whole production 
quantity. Each production unit must receive flight approval. 
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To recapitulate, the subsystem total cost is given by either 


(program specific subsystem--PS) 


(nonprogram specific subsystem-- (4b) 
NPS) 


Then the Subsystems Total NCU cost to the program is 


In the model, tiiere are L Program Components. Each cost associ- 
ated with the Program Components is a single valued function of the total 

subsystem cost, c^- . Thus, if the functions are represeted by U- (c-^ 

ss . . 

the contribution of the Program Components to the total NCU cost is given 


Then the total program NCU cost is 
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In the list of inputs, the total numbers of times each pair of 

similar (i.e., like hardware) subsystems will be assembled together 

must be specified; the p.. for the i^^ and {i , j = 1 , ... , M) 

* 

subsystems. Clearly, p. . = p.. . Corresponding to each p.. , or p.. , 

I J J I I J J I 

are numbers . v-^hich represent the cumulative effects of learning 

I J J I 

due to the number of times each pair combination is co-assembled. 

To estimate the savings from common assembly, the cost reduction 
factor 


is calculated. Then, the total subsystem cost is modified to a reduced 
value by computing 


This new. Adjusted Subsystem Total NCU Cost is then used in computing the 
Program Component costs. 

Hence, for the case of full commonality, relation (7), Total Program 
NCU Cost, is rewritten as 


It should be noted that in (7a) the cost contribution of the subsystem 
is unchanged from before. That is (other than the effect of amortizing 
costs over the design and production of multiple quantities of units), 
commonality savings appear only at the system level program component 
costs. 
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2 . Co st Estimating Re l ationsh ips ( C E R s ) 


In this section, another con'ponent of the Model --the CERs-- 
are presented. These CERs, Exhibits 13 through 28, relate a subsystem 
parameter to the cost expressed in NCUs. The subsystem parameters are 
usually weight with two exceptions, power for the electrical power sub- 
systems and pounds-thrust for propulsion. Each CER sheet contains tv/o 
curves, one for design/development and the other for hardware first unit 
NCU cost, with appropriate, different NCU cost scales. The range of the 
independent variables for each curve is extensive enough so as to include 
any feasible spacecraft which could be launched from the Shuttle. To use 
the CERs, first determine the appropriate value of the subsystem param- 
eter and then derive the corresponding NCU value. 

In developing these CERs, an extensive data base was collected, and 
analyzed and synthesized. (See Appendix A for a list of the data base.) 

Of the numerous reports, only several reports were considered to be di- 
rectly applicable. The actual cost data shown in (A31) (current value 
money) was deemed the most reliable basic data available. Although the 
subsystem definitions in (A31) were not considered to be standard, these 
subsystem definitions contained the standard subsystems as subsets. Using 
the data contained in (A46, A47) it was possible to disaggregate the cost 
data in (A31) and to derive the approximate raw dollar costs of the de- 
sign, development, and type approval testing and the total hardware cost 
for each standard subsystem for each of the programs of interest. 

It should be noted that actual cost will implicitly include the ef- 
fects of technological inheritance. Therefore, to translate "raw" actuals 
to that cost associated with doing the work with all new design and/or 
material means removing the effects of such inheritance. Again, the pre- 
vious work in (A46, A47) proved invaluable. In each of these reports, 
the inheritance estimates for each subsystem had been included as a by- 
product; therefore, the raw data could be "disinherited" to approximately 
determine the quantities. From these two documents, the numbers of test 
and flight articles fabricated were obtained. Report (A31) uses only the 
number of flight articles actually launched in estimating hardware costs. 


I 


V. 


f 
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Emphasis has been placed upon developing a standard unit of cost 
which will be constant rather than requiring the application of infla- 
tion or deflation factors. The raw data on costs are in current value 
dollars of the year spent. For developing the Cost Estimating Relation- 
ships for design and development and for the hardv/are cost it v^as neces- 
sary to convert all costs to a common base year. This was done with the 
aid of the "Aerospace Inflation Factors" found in (A18). Consequently, 
in all of the CERs and other relationships, between value and hardware, 
cost is measured in a unit defined as the Normalized Cost Unit (NCU). 
Because of the normalizing to the NCU, old CERs and new CERs can be fully 
utilized, compared, and interchanged. 

3. Commonality Evaluation Model Tables of Factors 


In addition to the CERs other relationships were also developed 
and are required as an integral part of the Commonality Evaluation Model. 
This section presents these six relationships in a tabular forma t--Tables 
3 through 8. 


4 . Commo nal ity E valuat i on Model Subs ystem Cost D e finitions 


As used in the CEM, the subsystem cost has the following com- 
ponents: design/development, hardware first unit cost and testing costs. 

The testing costs are considered in two parts. . The first testing part-- 
type approval--is generally included in design/development cost while the 
second--flight approval --is categorized as a separate cost. The follow- 
ing subsections provide expanded definitions of selected terms associated 
with the CEM. 


The design/development value corresponds to designing and 
developing the subsystem completely from scratch and so must be adjusted 
downwards for projects of "novelty fraction" less than 1.0. 


In context of current CER development, it is important 
to realize that the costs of a subsystem include not only the direct 
design/development and hardware cost but also the costs of testing the 


Table 3 

NOVELTY FRACTION ASSIGNMENT FOR S/S DESIGN & DEVELOPMENT (Np) 
Material and Fabrication Novelty 


Prior Design 
and Software 


Previously Used 
Materials and 
Fabrication 
Technology 


Minor Change in 
Materials 
Properties or 
in Fabrication 
Technology 


Significant 

Change 

in Materials or 
in Fabrication 
Technology 


Major Change in 
Fabrication 
or a Material 
with Little 
Experience in 
Spacecraft 
Usage 


Completely New 
Materials and 
Fabrication 
Technology 


Minor Design 
or Software 
Changes 

Significant 
Changes to a 
Prior Design 
or Software 


Major Change 
to an Old 
Design 

Completely 
New Design 
and Software 
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Table 5 

TYPE APPROVAL TESTING ARTICLES* (N^) 


S ubsystem Name 
Struc I 
Struc II 
Struc III 
Propulsion 
Guidance 
Attitude Control 
Communications 
Data Handling 
Power (elect) 
Science 


1 . 0 - 

3 

3 

3 

3 

4 
4 
4 
4 
3 

.4 


Novelty Fraction (Np) 


0.74- 0.49- 0.29- 

0.5 0.3 0^ 1^ 

3 2 2 

3 2 2 

3 2 2 

2.5 2 1.5 

3 3 2.5 

3 3 2 

3 3 2.5 

3 3 2.5 

2.5 2 1.5 

3 3 2.5 


.14- 

0 .0 

1 

1 

1 

1 

2 

1 

2 

2 

1 

i;5 


* 

In Type Approval Testing each test requires that a prototype unit be made 
Hence #Test - #Articles; = Nj - Nj/\ . None of the TA-Testing articles are 
used as Flight Articles; therefore, all of Flight Articles must be made 
separately after TA has been obtained. 
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Table 7 

COMMONALITY INTERACTION COEFFICIENT LEVEL SELECTION (IN PERCENT) 
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Subsystem Name 


1 

Structure I 


80 

70 





70 


2 

Structure II 

80 




80 

80 


80 

70 

3 

Structure III 










4 

Propul si on 

70 



60 






5 

Guidance 



60 


60 

70 




6 

Attitude Control 


80 


60 





60 

7 

Communications 


80 


70 


1 

60 


60 

8 

Data Handling 






60 



60 

9 

Power (elect.) 

70 

80 







60 

10 

Science 


70 



60 

60 

60 

60 
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components to be sure they can survive the spacecraft environment. The 
testing of subsystems typically occurs in two stages. First, the com- 
ponent(s) are tested for "Type Approval," which means they can physically 
survive the space environment and still function; for a new component ta- 
sign it is usual for either three or four type approval tests to be con- 
ducted before approval is given. 




t 




ft 


ft 


c. Flight Approval Test Cost 

After type approval has been obtained, the hardware flight 
articles can be produced. For each flight article there is further test- 
ing, although less severe, to be sure the produced items will also stand 
the environment. Those which pass this test are given Flight Approval 
and may be installed in the spacecraft. No matter how mature the design 
nor how often a similar, or even identical device, has been flov/n, it 
will always be required to pass the Flight Approval tests. 

Aside from producing components on an as -required basis (Progress 
SpecifiC”PS) for each spacecraft program or project as it evolves, there 
exists the possibility of acquiring components "off the shelf," from an 
inventory of standard-type components, or from a continuously operating 
production line. These subsystems or components are designated Non- 
Program Specific (NPS). The costs of such NPS components must be cal- 

I 

culated differently from those which are custom made for a single pro- 
gram. The essential feature for NPS components, from the standpoint of 
this model, is the achievment of cost savings associated with extended, 
serial production. Although NPS reduces the design/development and type 
approval costs, flight approval test costs are not reduced through the 
use of Non-Program Specific components. 








d. Novel ty 

The cost of design and development is split approximately 
55 percent "true" design/development and approximately 45 percent test- 
ing, if the subsystem is being developed from scratch. In the case of 
novelty less than 1.0, the design development costs must be appropriately 
reduced by the estimating, for each subsystem separately, the amount of 
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novelty in the nevy design. If a new material is to be used with an older 
design, "novelty fraction" = 1.0 ; and similarly if an old material is 
to be used with a new design. For intermediate values of novelty. Table 8 
shows the appropriate relationship between "novelty fraction" and the 
design/development reduction factor. 

Har dware First Unit Cost 

The hardware value read from the CER is the true first unit 
cost for a subsystem manufactured to spacecraft standards, and needs no ad- 
justment. For estimating the total hardware cost, it is first necessary 
to know the number of flight articles to be acquired. The number to be 
acquired is the number to be flown plus the number of fully assembled 
space spacecraft. The number of flight articles is in addition to the 
number of type approval test articles. Table 4 contains suggested values 
to be used for the additional numbers of hardware units required for test- 
ing as a function of novelty. The values provided are expected numbers 
based on the experience of several programs. 

f. Non-Program Specific Hardware Costs 

If NPS hardware is acquired, the model reflects amortized 
production unit cost for the full production run, and the spacecraft pro- 
gram is charged only unit acquisition cost and flight approval testing 
for the acquired hardware. In this mode, the model does not permit the 
assignment of design/development cost and its related type approval 
testing cost as a separate component. 

C . Learning Curve Approach for Common Pairs Development 

1. Definition of Common Pair Interactions 

Common pair commonality occurs if the same subsystems are to be 
paired in two or more programs or projects. For instance, if the same 
Guidance subsystem and Attitude Control subsystem are to be used together 
in three different projects, then common pair commonality exists with re- 
gard to that combination or pair of subsystems. Additional savings will 
accrue due to that commonality application. 
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The first step in the development of the approach to incorporat- 
ing the cost reduction due to common pair commonality was to qualitatively 
define the interactions between various pairs of common subsystems. This 
was accomplished by constructing a matrix of the subsystems and assigning 
rankings related to the potential cost reduction impact of each of the 
pair intersections. 

The cost reduction impact of a pair is determined by the amount and 
complexity of the interaction between them. If there is no interaction 
or only negligible interaction, the potential for cost reduction through 
multiple interfacings of that pair is negligible. If the interaction is 
very intimate and complex, the opportunity to reduce the cost of inter- 
facing that pair through a learning process is large. 

A four-level qualitative ranking index was used. Level one repre- 
sents the most intimate and complex interactions. Level two represents 
an intermediate range. Level three represents a lesser but still sig- 
nificant interaction. A blank intersection represents negligible inter- 
actions. The matrix is shown in Exhibit 29. 

2. Approach 

The development of the learning curve technique used to derive 
the adjustment factors for adjusted subsystems costs, and thereby, the 
reduction in the Program Components costs where common pairs are involved, 
began with a simple hypothesis based upon experience and observation. 

Essentially, the hypothesis states that management and integration 
functions become progressively simpler and more efficient, similar to 
manufacturing tasks, when identical items are brought together repeatedly, 
even in different systems. This effect can be observed in the produc- 
tion of aircraft and, perhaps most graphically, in ships. Interestingly 
enough, it can also be observed in the integration of common software 
subroutines and logic into complex computer programs. 

A further observation indicates that the rate of increase in effi- 
ciency of the management and integration functions is somewhat propor- 
tional to the complexity of the interface between the pairs of items. 
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1 

I 

\ 

i 

■< 

) 

1 




72 


Planning Systems and Sciences 


Exhibit 29 

MAJOR f';nction commonality interaction factors 


structure I 
Structure II 
Structure III 
Propulsion 
Guidance 
Attitude Control 
Communications 
Data Handling 
Power (elect.) 
Science 



2 


3 

3 


2 3 


2 


1 

1 1 2 
1 

2 1 
1 

1 1 1 




1 

1 

1 

1 


Value: 1 = Highest Interaction 

2 = Mid Interaction 

3 = Lowest Interaction 
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Little of this improvement (an insignificant amount, if any) could 
come from the kind of learning of manual tasks represented by the learn- 
ing curves applied in manufacturing operations. Observations, however, 
indicated that the patterns followed v/efe somev/hat similar to the typical 
learning curve shape. Considering the fact that the manual task learning 
curves almost always apply to a single organization, whereas the observed 
improvements in management and integration sometimes apply to different 
organizations and e/en to different end systems, transferable learning has 
to be involved. 

This conclusion leads to the realization that the underlying causal 
factor is better documentation. Where items are intentionally develdped 
to be applied more than once, in more than one system, and, perhaps, by 
more than one organization, a significant effort is committed to the devel 
cping of comprehensive, accurate documentation which defines the proper- 
ties of the interfaces. This includes, for example, the methods of check- 
out and the interface wiring diagrams. This realization prompted a liter- 
ature search to determine if similar observations had been made elsewhere. 

The only evidence that the learning theory for "knowledge work" (as 
contrasted with that for manual tasks) was being pursued was found in the 
field of computer programming. The data indicate a situation quite simi- 
lar to the hypotheses proposed above. In some cases, the documentation 
is replaced by interteam communication. Although a direct comparative 
analogy cannot be drawn at this time, the findings in the programming 
field appear consistent with the concept of "transferable knowledge 
learning." 

In order to apply this concept to the impact of common pairs on Pro- 
gram Component Costs, it was necessary to establish the "slop.. of the 
learning curves to be used, as well as the start and the end points. 

a. "Slopes" 

The 8Q percent learning curve is usually considered, and 
fairly well demonstrated, to be about the best that is normally achieved 




^Documents 49, 50^ 51, and 52 in Appendix A. 
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In complex aircraft manufacturing operations. Since this represents 
improvements (or learning) in primarily manual operations, it was rea- 
soned that this "slope" or rate of learning effect should be at least 
equalled by "transferable knowledge learning" which occurs principally 
through documentation rather than through conditioning by repetition. 

This assumption could not be verified directly by historical data since 
this type of commonality application has not yet occurred in significant 
portions of unmanned space systems. Reviews of cost data from some pre- 
vious space projects that involved a very high order of inheritance in 
some subsystems, however, revealed cost deltas that lend support to the 
80 percent "slope" selection. The use of an 80 percent learning curve 
to establish the reduction factor for determining adjusted subsystem 
cost was accepted for application to the least complex common pair 
interactions. 

More complex common pair interactions v/ere judged to benefit at a 
faster rate from "transferable kno^^rledge learning" since the more com- 
plex the interaction is, the greater is the amount of information about 
the interface that can be transferred through documentation. Based on 
this reasoning, 70 percent and 60 percent learning curves were tried for 
the intermediate and most complex interactions, respectively. Program 
component costs were computed using these curves for some typical sub- 
system costs and common pair combinations. The results were satisfying 
because they produced approximately the cost savings that our Judgment 
and experience had led us to anticipate for the test cases. Following 
this exercise, 70 percent and 60 percent curves were selected for the in- 
termediate and most complex interactions, respectively. 

bi. Starting Points 

It was considered inappropriate to start the learning 
curve at the first unit since, for most unmanned space projects, the first 
two or three units are essentially prototypes. Therefore, the correcting 
and updating of documentation would not really provide significant learn- 
ing for the second unit. Based on these considerations, the second unit 
was selected for the starting points of the learning curves. 
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Since the basic assumption underyling the application of 
the "transferable knowledge learning” technique is that the bulk of the 
learning comes through the preparation, correcting, and upgrading of doc- 
umentation about the properties of the interfaces, it is also necessary 
to recognize that this process does not continue indefinitely. 

In manufacturing operations, v/here the learning applies primarily 
to manual tasks, the process continues as long as the manufaeturing goes 
on and the curves flatten out to a slowly changing asymptote. In the 
situation at hand, however, the cutoff comes fairly early because the in- 
crease in the amount of information transferable through documentation 
will be truncated after a relatively small number of units. The number 
of units selected for truncation of the learning curves is ten. Few 
cases are likely to occur where the documentation will continue to be 
improved after ten units have been produced. 

3. Learning Curve Computation 

The tabulated values for the learning curves used in the model 
were calculated by first calculating the unit learning curves for each 
of the selected slopes.' Next the cumulative average values for the first 
three units were calculated for each of the three curves. From these cal 
culated cumulative average values,’ the "slopes" or exponents for the cum- 
ulative average curves could be determined. The first ten values were 
then computed for each of the three cumulative average curves. These 
values are shown in Table 7. 


D . Conclus i ons and Recommendatio ns 


1. Conclusions 




When used in accordance with the instructions provided, the Com 
monality Evaluation Model provides a good comparative evaluation of the 
costs of unmanned planetary space projects involving various amounts and 
kinds of commonality among their elements. 


Application of the model is straightforward and is easily exercised 
by manual operations. It is equally well suited to automated computation 
and can be programmed for small computers with a minimum of difficulty. 
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The CommonaTity Evaluation Model was developed for a specific set 
of space projects . The model could be extended to other cl asses of 
space projects w1 th approprl ate modi ficatl on of the CERs and the model- 
speclfic factors. 

The utilizing and realization of cost in a Normalized Cost Unit> 
rather than using "then" or real year dollars, eliminates the necessity 
for inflation/deflation correction and eases the interpretation of 
results. • 

A generalized relationship was not developed, within the scope of 
this effort, that related changes in operational phase costs to increased 
commonality within the Gonstraints of the existing CERs. The impact of 
these savings is provided for within the framework of the model, 

2. Recommendations 

Increased hardware and software commonality constitutes an ef- 
fective method of lowering the costs of unmanned interplanetary space 
projects. The Commonality Evaluation Model should be used to make com- 
parative evaluations of various commonality approaches. 

Further development of the Commonality Evaluation Model is possible 
and should be undertaken. The model should first be extended to incor- 
porate the impact of various management modes because the impact of man- 
agement modes and commonality can be either mutually reinforcing or dis- 
sipative in various combinations. Sufficient data to allow this extension 
is in existence and should be expToi ted . 

The model should also be extended by the development of new CERs to 
allow comparative analysis at lower levels of breakdown for the hardware 
elements. This would also allow the structure to be extended to more 
closely approach the nev/ fraemwork and structure also developed during 
this effort. 
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Documents containing useful information: 

1. Advanced Systems Cost Estimating Techniques, Volume II: Low Cost 

Systems Analyses, PRC, PRC D-2108, Jan. 1976 

2. Advanced Systems Cost Estimating Techniques, Volume III: Logistics 

Concept & Implementation Plan, PRC, PRC D-2108, Jan. 1976 

3. Experiment Compendium, JPL, RP-001-01-99 

4. Low Cost Program Practices for Future NASA Space Programs — 
Technical Report, Lockheed, LMSC-D469857, Dec. 1975 

5. Low Cost Program Practices for Future NASA Space Programs— 

Final Report, Volume II: Appendix; Lockheed;- LMSC-D469857, 

Dec. 15, 1975 

6. Spacecraft Platform Cost Estimating Relationships, Draft w/ 
changes; Werner Gruhl ; Dec. 2, 1970 

7. Optimized Cost/Performance Design Methodology, Volume II: Data 

Review & Analysis, Book 5-Cost; McDonnell Douglas, G975, April 
1960 

8. MVM 1971 Actuals, JPL 

9. MVM 1973 Actual Costs, JPL 

10. IITRI letter to Ruhland, Preliminary numbers in use for subsystem 

and support function costs--various planetary programs; July 20, 
1972 . 

11. Space Shuttle Cost Model, General Dynamics, GDC-ERR-1461, Dec. 

1969 

12. Lunar Orbiter Program, Boeing, D2-81254-8 

13. Spacecraft Platform Subsystem Complexity Level Cost Estimating 
Model (Version III), Werner Gruhl, Nov. 1972 

14. Unmanned Spacecraft Cost Model, SAMSO, May 1969 (revised) 

15. Unmanned Spacecraft Cost Model, Phase I update, SAMSO, Aug. 1971 

16. Unmanned Spacecraft Cost Model, SAMSO, July 1973 (2nd Edition) 

17. Unmanned Spacecraft Cost Model, SAMSO, TR-75-229; July 1975 

(3rd Edition) 

18. Unmanned Spacecraft Cost Model Updated Cost Estimating Relation- 
ships and Normalization Factors (Interim Report); SAMSO, Jan. 1977 
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19. Survey of Lunar/Plane to ry Programs for Cost Forecasting Analysis; 
IITRI; TM G-9; Feb. 23, 1972 

20. OSO-I Final Report; HAC; RP-232-P1-99; Jan. 29, 1974 

21. Unpublished PS&SC Memo (NASA/Wash, trip); Jan. 11 & 12, 1977 

22. Models of Wartime Inflationary Pressure; Sobin; Dec. 5, 1968 

23. Historical Cost Data--Vela Program; TRW; Vela-CS-001-73; April 17, 
1973 

24. Cost Study of Synchronous Meterological Satellite Program; 
Philco-Ford; July 26, 1974 

25. Cost Analysis ATS A/E Program, Final Report, HAC, Feb. 1973 

26. Equipment Specification Cost Effect Study, Phase II Final Report, 

Vol. I: Executive Summary; RCA; Nov. 30, 1976 

27. Standard Equipment Announcement, various, NASA, 1975 & 1976 

28. Cost Benefit Analysis, NASA-LCSO, Aug. 1976 

29. Atmosphere Explorer Low Cost Study Report, RCA, Sept. 1974 

30. Mariner Venus/Mercury 1973— A Study in Cost Control, Nov. 1973 

31. Manpower/Cost Estimation Model for Automated Planetary Programs-2, 
SAI, SAI-1-120-339-C2, April 1976 

32. Cost Analysis Study of the ITOS D, E, F, G, & E 2 Spacecraft, 

RCA, 1976 

33. Cost Data Package, Defense Meteorological Satellite Program, 

Block 5D, SAMSO, March 1975 

34. Atmospheric, Magnetospheri c and Plasmas in Space (AMPS) Cost 
Model (2 Vol s.); PRC, Tech. Brief No. 15/PRC D-2106; Jan, 31, 

1976 

35. CERs and Percentage Relationships for Estimating the Cost of 
Functional Factdrs; PRC, Tech. Brief No. 24/PRC D-2117; Oct. 20, 
1976 

36. Systems Cost/Perfprtnance Analysis (Study 2.3) Final Report; 

Vol. i: Executive Summary; AerospaGe,ATR-75(7363)-3; March 31, 

1975 
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37. Systems Cost/Perfomance Analysis (Study 2.3); Aerospace; 

Feb. 14, 1974 

38. Systems Cost/Performance Analysis (Study 2.3) Final Report, 

Vol. II: Systems Cost/Performanee Model ; Aerospace, 

ATR- 74(7343)-!; Sept. 27, 1974 

39. Systems Cost/Performance Analysis (Study 2.3) Final Report, 

Vol. II, Appendix A: Data Base; Aerospace, ATR-74(7343)-l; 

Sept. 27, 1974 

40. Systems Cost/Performance Analysis (Study 2.3) Final Report, 

Vol. Ill: Programmer Manual & Users Guide; Aerospace, 

ATR- 74(7343)-!, Sept. 27, 1974 

41. Advanced Space Program Studies — Overall Executive Summary, 

' Aerospace, ATR- 74(7338)-!, Sept. 1973 

42. Aerospace Program Review— NASA Study 2.1, Operations Analysis, 
Aerospace 

43. Manpower/Cost Estimation Model, Automated Planetary Projects, 
SAI, SAI 1-120- 194-Cl, March 1975 

44. Feasibility Study of Electronic System Complexity as a Measure 
of System Cost, Final Report; Spacecraft, Inc.; May 27, 1964 

45. Earth Orbit Shuttle Cost Model, L. Raphael and R. Krueger, 
Aerospace, Aug. 1969 

46. Cost Prediction Model For Unmanned Space Exploration Missions, 
Final Report; PRC, PRC R-1299; Dec. 15, 1969 

47. JPL Cost Model (1976 Version) 

48. Challenger Study Team Meeting Minutes, JPL, 1975-1976 

49. A Close Look at Brook's Law, Gordon, R.L. and Lamb, J.C., 
Datamation , Vol. 23, No. 6, June 1977 

50. A Working Measure of Productivity, Johnson, J.R., Datamation, 
Vol. 23, No. 2, February 1977 

51. The Mythical Man-Month, Brooks, F. P. , Jr., Datamation , Vol. 20, 
No. 12, December 1974 


52. Why Projects Fail, Keider, S.P., Datamation , Vol. 20, No. 12; 
December 1974 
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Documents Evaluated but not used: 

1. Advanced Spacecraft Subsystems Cost Analysis, Structure/Subsystem 
Integration, Final Oral Briefing*, McDonnell Douglas, MDC E0083, 
Jan. 12, 1970 

2. Advanced Spacecraft Subsystems Cost Analysis, Environmental 
Control System*, McDonnell Douglas, MDC E0084; Jan. 12, 1970 

3. ASSCAS SCS {Adv. Spacecraft S/S Cost Analysis Study, Stabiliza- 
tion and Control System)— Final Review, MP-3, Jan. 8, 1970 

4. Alternative Approaches to Using Peacetime and Wartime Costs in 

Limited War Cost-Effectiveness Studies, John J. Surmeier, P-4052, 
April 1969 ; 

5. The Systems Approach to Life Cycle Cost Analysis; Convair-GD; 

Feb. 19, 1969 

6. Low Cost Development of Compnsite Index of NASA Specifications — ^ 
Vol. 1, Vol. 2 (Appendices A-E), Vol. 3 (Appendix F); PRC; 

Nov. 15, 1975 

7- The Use of Tchebycheff-Type Inequalities To Bound the Upper 
Limit of a Cost Estimate, M.J. Zusman (IDA), Jan. 1969 
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The unit of cost used in the Commonality Evaluation Model (CEM) is 
a normali 2 ed value called the Normalized Cost Unit (NCU). All of the cost 
estimating relationships (CERs) and other relationships are expressed in 
terms of the NCU. Therefore, attempts to use this model to predict actual 
dollar costs of spacecraft hardware or programs will not produce meaning- 
ful results. 

The CEM is limited to the pre-launch phases of the unmanned space- 
craft program. Table 1 presents the reference order of the functional 
subsystems treated by the CEM. Table 2 presents, in order, the Program 
component or system level costs implemented in the CEM. 

Several terms or concepts used in conjunction with the CEM require 
brief explanation. These terms are Novelty Fraction, quality procure- 
ment, and commonality. . 

A particular device or design is "technically mature" when it is 
similar to a recent predecessor in both design and materials of construc- 
tion. In this CEM, the degree of technological maturity of the system is 
represented by a "Novelty Fraction." Novelty fraction values fall into 
the range of 1.0 to 0.0, where 1.0 is equivalent to a new design and/or 
materials and 0.0 is equivalent to a tried design and previously used 
materials. 

The costs of quantity procurement (non-program specific) equipment 
are calculated differently from those made for a single program (program 
specific). Section III describes this procedure which permits realizatipn 
of the cost savings associated with serial production. It is recognized 
that the first user of a quantity-procured item generally absorbs the 
design and development costs. However, in order to provide meaningful 
commonality comparisons, the design and development costs are prorated 
among the total units produced. 

For purposes of the CEM, commonality is defined as follows: major 
components of the spacecraft subsystems are common to a series of programs 
or projects, or a program with a significant number of spacecraft has one 
or more components common to each spacecraft. 
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COMMONALITY EVALUATION MODEL SUBSYSTEMS 


1. Structure I (fixed, immovable mechanical structure and supporting 
members of the spacecraft 

2. Structure II (mechanical devices, hinges, springs, dampers, rotating 
joints, pin-pullers, etc.) 

3. Structure III (pressurized structure, typically cold gas vessels and 
rocket- fuel and oxidizer tankage) 

4. Propulsion (specify kind, may be ion-drive, chemical rockets, or 
solar sails) 

5. Guidance (includes star trackers, sun sensors, and the Central Com- 
puter and Sequencer, if any, in the spacecraft) 

6. Attitude Control (includes the roll, pitch, and yaw sensors, the 
means for rotating the spacecraft about its axes, and any expendable 
stores associated with such control) 

7. Communications (includes the on-board radio systems from the modul- 
ators to the antennae for X-mitters and the antennae to the demo- 
dulators for the receivers; it will include any special power con- 
ditioning which is used by the radios exclusively) 

8. Data Handling (includes all data collection and on board data 
storage devices and all encoding and pre-modulation modification of 
the on-board generated data stream) 

9. Power (includes the power generation, solar Cell or other, and all 
conditioning for the spacecraft power service, but not any dedicated 
power conditioning associated with a particular instrument or 
subsystem) 

10. Science (includes all scientific instruments on board the spacecraft; 
does not include supporting structure or scan platforms unless a 
functional part of the instrument, not just supports or pointing 
aids) 
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COMMONALITY EVALUATION MODEL 
PROGRAM LEVEL COMPONENTS 


Program Management (all the costs of administering the spacecraft 
program which are program specific) 

Systems Analysis and Systems Engineering (the costs usually paid 
for the systems level technical effort in design and in such areas 
as the engineering part of systems integration) 

Systems Test (the costs of all systems level testing of the assem- 
bled spacecraft, but not of any single subsystem or component) 

Quality Assurance and Reliability (the costs of all the system level 
QA&R effort, but, again, not that of any component) 

Assembly and Integration (the costs of assembling the subsystems 
and integrating them into a functioning spacecraft, exclusive of 
testing) 

Operational Support Equipment (the necessary test and checkout equip- 
ment for the spacecraft at the system level; subsystem OSE is a part 
of the cost of subsystem hardware) 
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III. MODEL USE 


This section contains the details of the Commonality Evaluation 
Model implementation and use. All required CERs are contained in either 
Appendix A (subsystem CERs) or Appendix C (program-level component CERs). 
The required tables are located in Appendix B and suggested computational 
forms are in Appendix D, 

To exercise the CEM, a relatively straightforward approach has been 
implemented. The approach basically determines the NCU cost of design/ 
development, hardware production, and all testing for each subsystem. 

The sum of these NCU costs determines the cost associated with the hard- 
ware portion of the program cost. The program-level component NCU costs 
are determined as a function of hardware component NCU cost. The sum of 
the two components is the program NCU cost. 

When components or subsystems are utilized which do not have to be 
redesigned or where the hardware cost is to be prorated among several 
programs or projects, a modification of the basic approach is required. 

This reduces not only the hardware component cost but also reduces the 
program-level component. 

Sub-section A then describes the basic process, a process which is 
similar to that employed fay the current JPL cost model. Sub-sections B 
and C describe the methodology employed to determine cost reductions due 
to commonality, while Sub-section D describes the methodology for deter- 
mining program- level component costs. Sub-sections E and F briefly discuss 
the completion of the calculations and our approach to comparing among 
several alternative cases. 

A. Subsystems Costs 

A set of CERs relate subsystem parameters to cost expressed in NCUs. 
Each CER Exhibit contains two curves — one for design/development and 
another for hardware first unit cost. To determine the subsystem cost 
use Fonn 2 and determine the appropriate subsystem parameter value. 

Then, using the appropriate CER, determine the corresponding NCU value. 
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The design/development CER values correspond to new design and its develop- 
ment for a subsystem. Therefore, the CER value is adjusted downward for 
subsystems with novelty fractions less than 1.0. The subsystem hardware 
value read from the CER is the first true unit NCU cost for a subsystem 
manufactured to spacecraft standards. 

The cost of design/development is split approximately 55 percent 
"true" design/development and 45 percent testing for a new design sub- 
system being developed. To reduce design/development costs for novelty 
values less than 1.0, estimate the amount of novelty in the new design 
for each subsystem separately. New material with an old design or old 
material with a new design are equivalent to a Novelty Fraction of 1.0. 

Table B-1 presents an array for determining the appropriate Novelty 
Fraction. Table B-2 presents the relationships between novelty and the 
design/development reduction factor. After reducing the CER values of 
the component subsystem costs, total them to determine the design/ 
development contribution to the total spacecraft program cost. 

Hardware cost estimates are dependent upon the quantity of space- 
craft to be flown. Table B-3 contains suggested values to be used for 
the additional numbers of hardware units required for testing as a func- 
tion of the Novelty Fraction. Hardware costs are computed using Form 3. 

B. Common Subsystem Component Costs 

Computing the cost of a common component subsystem for a single 
spacecraft program or project (i.e,, one of the alternative cases) utilizes 
a different procedure. 

For each subsystem it is necessary to estimate or know the total plan- 
ned number of production sets. Use the appropriate subsystem parameter 
and determine the CER costs as before. A Novelty Fraction of 1.0 is rec- 
ommended; i.e., a full testing program is contemplated. 

Enter the CER and quantity to be produced on Form 1. Obtain the num- 
ber of test articles from Table B-3. The total subsystem production run 
6ost is obtained by summing the design/development, type approval testing, 
hardware, test hardware, and the production NCU cost of the required num- 
ber of subsystems. Cost advantages of production line savings are calculated 
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from Table B-4. Obtain the fraction of first unit cost applicable to the 
selected production quantity, Multiply the total number produced by the 
first unit cost and by the appropriate reduction factor. To this total, 
add the design/development costs and divide by the total quantity produced. 
This quotient is the amortized per unit cost to the spacecraft program 
and should be entered in the hardware unit cost column on Fom 3. 

C. Total Subsystem Cost Adjustment for Commonality 

If a number of previous occurrences of spacecraft with common sub- 
systems have successfully passed through all the program phases, using 
these subsystems will result in a commonality cost savings. 

To compute a lower or Adjusted Subsystem Total Cost (ASSTC) to reflect 
such usage, use Form 4, part A and B. Enter on part A the number of tiroes 
a given pair of subsystems is common to a spacecraft (i.e., all the space- 
craft on which it is, was, or will be used). Using these numbers, use 
Table B-5, for the percent interaction of each pair of subsystems given, 
enter Table B-6 and determine the savings allowed for each interaction. 

If the Table B-5 interaction value is pot specified, use the value of unity 
(1.0) for Table B-6. Enter the Table B-6 values in the appropriate inter- 
action intersections on part B of Form 4 in columns 1 through 10. Each 
interaction factor is entered in two places for each pair of subsystems. 

If there is no interaction, or the value of the interaction in Table B-5 
is zero or not specified, unity (1.0) is assumed; however, for convenience, 
these have been pre-printed on Form 4, part B. 

When all the interaction pair values have been entered on part B, 
the row products of columns 1 through 10 are computed to develop a Common- 
ality Factor. Each subsystem cost is multiplied by this commonality factor 
to determine an adjusted subsystem NCU cost. 

The sum of all the adjusted subsystem costs is the Adjusted Subsystem 
Total NCU Cost (ASSTC). 

D. Program-Level Component Costs 

Program-Level Component costs utilize the system level cost categories 
defined in Section II. Form 5 will be used for the computation. 
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CERs are provided for each of the program component of costs, where 
the independent variable is either the Subsystem Total NCU Cost or the 
Adjusted Subsystem Total NGU Cost. 

With the appropriate value of either the SSTC or ASSTC, use the CERs 
to find the proper values to enter on to Form 5. 

For program-level component costs, there is no adjustment other than 
the SSTC adjustment to ASSTC to account for the due to common subsystems 
savings. 

E. Spacecraft Total Pre-Launch Cost s 

Sum all of the entries on Form 5. Use the unadjusted value of SSTC 
for the hardware component share of the program. 

F. Comparisons 

If it is desired to make comparisons between altev'natives, each 
alternative must have a set of calculations. 

G. Flow Chart 

Exhibit 1 depicts the computational process utilizing the forms con- 
tained in Appendix D. The diagram, for simplicity, shows a comparison 
involving two alternative cases. 
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IV. EXAMPLES 


The purpose of this section is to demonstrate the principles and 
uses of the model. The example is divided into three applications, pro- 
gressing from familiar ground through full utilization of all the model 
features. The first application demonstrates the CEM in a mode which 
essentially emulates the current JPL Cost Model. The second application 
extends the first by employing the concept of Novelty Fraction and illus- 
trating the computation of system cost with a portion of a subsystem 
made up of non-program specific components. In a like manner, the third 
application extends the second by illustrating the cost effects of com- 
mon pair assembly and several quantity-procured subsystems, and, in par- 
ticular, illustrates the computation and application of the adjusted total 
subsystem cost. 

With this purpose in mind, the three applications of one example 
are included only for illustration purposes to demonstrate the straight- 
forward, step-wise design of the CEM. 

These three applications, neither singularly nor collectively, 
exhaust the versatility of this Model. They are intended to introduce 
the user to the main features. Application 2 demonstrates the CEM's 
fl exibility. 

A. Overview 

Of the three applications, the first primarily assumes the project 
contains all new design with the usual number of interplanetary scientific 
mission flight articles - three. 

The second application demonstrates the concept and use of the 
Novelty Fraction as well as illustrating the flexibility of the Model. 

That is, the informal expansion beyond the formal methodology is demon- 
strated by assuming that half the communications subsystem is to be non- 
program specific, while the remainder is program specific, i.e., made 
specifically for this spacecraft project. 

The last application exercises all of the features of the Model. 

Four subsystems are non-program specified and a significant number of 


10 


^ 

Planning Syslems and Sciences 

subsystem common pairs will be utilized. This application demonstrates 
the methodology Utilized to account for savings attributable to 
coiraionality. 

B. Model Preparation - 

In order to exercise the CEM for the stated applications, two addi- 
tional items are required. These two items are the input parameters and 
the computation forms. Table 3 contains the input parameters for the 
example. Shown below is an enumeration of the forms required for each 
application. Sample forms are contained in Appendices B-D. 


Form 


Application 
1 2 3 


1 

2 

3 

4 Part A 

4 Part B 

5 


X 

X 


X 

X 

X 


X 

X 

X 

X 

X 

X 


As an aid to the user, Table 4 contains'the nomenclature used throughout 
the various computation forms. 

For ease of computation, it Is suggested that the first computational 
form to be completed is Form 1, followed by 2 and then 3. Following the 
completion of Form 3, complete Form 4, Parts A and B, in sequence. Form 5 
is the recap form which contains all of the various subtotal data as well 
as the comparison data. 
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TABLE 3 




EXAMPLE INPUT PARAMETERS 


Parameter 
Application 
Subsystem Name 


Parametric 
Val ue 
aTT 


Novelty 
Fraction 
1 2 


Learning 
Saving Curve 
2 3 


Units 


Number 
Production 
Arti cl es 
2 3 


1. 

Structure I 

lbs 

200 

1.0 

.5 

.3 

- 


2: 

Structure II 

lbs 

30 

1.0 

.5 

.3 



3. 

Structure III 

lbs 

150 

1.0 

0 

0 



4. 

Propulsion 

Ibs-T 

50 

1.0 

0 

0 



5. 

Guidance* 

lbs 

:-50 

1.0 

.7 

1.0 

.85 

10 

6. 

Attitude Control 

lbs 

• 70 

1.0 

.7 

1.0 

.85 

10 

7. 

Communications 

lbs 

100** 

1.0 

1.0 

1.0 

.85 .80 

10 15 

8. 

Data Handling 

lbs 

10 

1.0 

.8 

1.0 

.90 

20 

9. 

Power (elect) 

KW @ 
1 AU 

.8 

1.0 

0 

0 



10. 

Science 

lbs 

100 

1.0 

1.0 

1.0 




Pairwise installation count for construction of Application 3, Form 4-part A 

*^5,6 ■ *^5,7 ^ *^5,8 " ’^6,7 " ^6,8 " *^7,8 ' others -3 

*6uidance - Mission Fly By 

** For Application 2, the 100 lbs is divided 50 lbs for non program specific and 50 lbs of program 
specific communications. 
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TABLE 4 


Planning Systems and Sciences 


NOMENCLATURE USED ON THE COMPUTATION F0RI«5S 


Design/Development Reduction Factor 
Production Learning Cost Reduction Factor 



Novelty Fraction 


Number of Flight Articles 


Number of Type Approval Tests 
Number of Type Approval Test Articles 


Commonality Interaction Coefficient 


Application 1 


Planning Systems and Sciences 


The spacecraft is defined by the parametric entries in columns 1 of 
the Fonns 2 and 3. Using the Subsystem parameters, 2-1 and 3-1, determine 
the appropriate NCU values from the CERs and fill in columns 2 on Forms 
2 and 3, The application program starts with all new design; therefore 
set Np to unity for all subsystems (2-3). Consulting Table B-3, find 
the number of Tests and Test Articles required. Enter Nj into 2-5 and 
into 3-4. The last input required is the number of Flight Articles - 
(3-5) - 3 - the usual number for an interplanetary scientific mission. 

The computation proceeds as indicated in the column headings of Forms 2 
and 3. Since this is an entirely new spacecraft, no savings due to learn- 
ing are appropriate. 

The Subsystem Total Cost (SSTC) is calculated on Form 3. The 
Program Component costs can be read from each appropriate CER and entered 
in the appropriate places in Form 5 (shown in E of this section). 
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PROGRAM SPECIFIC SUBSYSTEM DESI6N/DEVEL0PRENT «CU COSTS 



(T) CD 


Des/Dev 

Parameter Value CER Value 


Symbol 

Source 

Subsystem Name 
Structure I 
Structure 11 
Structure 111 
Propulsion 
Guidance 

Attitude Control 
Communications 
Data Handling 
Power 
Science 


i NPUT 


_PS NFS 

200 

30 


150 

50 

SO 

70 


100 

60 


0,8 

100 


CER 

2.53 

2.7 

10.5 
1,711 . 

m,5 

11,2 

9,1 

12.5 
_785 

8.3 


APPLICATION 1 ■ Form 2 


CD 

0 

© 


0 

0 

Novelty 

Fraction 

Des/Dev 

Reduction 

Factor 

Number of 
Type Approval 
Tests 

Des/Dev 
NCU Cost 

Test NCU Cost 

Subsystem 
Des/Dev 
NCU Cost 

,^F 

Input 

h 

Table B-2 

Nj 

Table B-3 

.55 X (D X (2) 
X© 

.09 x{T) X (D 

0 + 0 

1.00 

1.00 

3 

278.30 

136.62 

414.92 

1.00 

1.00 

3 

A'l.SS 

21,87 

66.02 

1.00 

1.00 

3 

866.25 

425.25 

1,291.50 

1,00 

1.00 

5 

A7.05 

23.10 

70.15 

1.00 ’ 

1.00 

4 

398.75 

261.00 


1,00 

i.OQ 

A 

031.20 

282.20 

713.44 

hOO 

1.00 

0 

500.50 

327.60 

828.10 

1.00 

1.00 

A 

412.50 

260.28 

672.78 

1,00 

1.00 

3 

305.00 

169. 5S 

510,96 

1.00 

1,00 

4 

056.50 

293.80 

. 755.50 


Subtotals 

Subsystem Design/Develophent HCU Cost CSSD/DC) 


L3,781,OoJ 12,206.32 


t,987..32J 






m 





. •: j.. 

^ . L. 



SUBSYSTEM HARDWARE COSTS 




(D 

(3) 


© 


• ' ;; ■' 

Parameter Value 

iHardi^are 
Unit Cost 
CER Value 

Hardware Unit Cost 

Number of 
Test 
Articles 

Humber of 
Flight 
Articles 

Subsystem 
Hardware 
NCSLCost . 

Symsol 

Source 

Input 

CER 

@ X (D Form 1 

Ryfi 

Table B-3 

,%A 

Input 

C® + CD ) X 


APPLICATION 1 


Form 3 


(D 


Flight Article 
Test Cost 


Hardware 
NCU Cost 


.09 X .5 X (2-(T)) (D+(7) 

X (2-(2)) 


Subsystem Name 


PS 


NPS 


PS NPS 











Structure 11 

■3n 

.A3_ 

12.90 .. 

3 

3 

77.40 

71.87 

99.77 










Structure 111 

IRO ... 

. JL . 

A6.50 

3 

3 

279.00 

425.25 

T.4.25 









Propulsion 

so 

.0309 ' 

1.55 

3 

3 

9.27 

23.10 

32,37 

' ■ 1 









Guidance 

.50 

.51. 

_25i5.Q__ 

4 

3 

178.50 

195.75 

574.25 










Attitude Control 

. 70—..., 

■ .56 _ 

39.20 

4 

3 

274.40 

211.68 

486.03 










Communications 

100 

.57 

57.00 

4 

3 

399,00 

245,70 

644.70 










Data Handling 

fin 

1.A3 ■ 

85.80 

_4 .... 

3 

600.60 

202,50 

803.10 










Power 

0.8 

107 

85.60 

3 

.3 

513,60 

169,56 

633.16 










Science 

lOD 

.645 

G4.5Q 

4 

.3 

451.50 

224,10 

675.60 



















Subtotals 

Subsystem hardware NCll cost (SSHWC) 





[I^D88’f07l 


^944._20_ ] 
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D. Application 2 

To illustrate the concept and use of Novelty Fraction, this applica- 
tion assumes half the Communications subsystem is to be common, and the 
other half made specially for this spacecraft program. Consequently, the 
appropriate entries are made on Form 1, as indicated, using half the 
weight of the whole Communications subsystem as the subsystem parameter 
value; the other half of the subsystem is calculated using the usual 
methods on Form 2 and Form 3. Notice that on Form 3, where the total 
hardware cost is obtained {column 3), it is necessary to total the two 
subsystem component costs together to derive the subsystem unit hardware 
cost. When the Flight Approval Test cost is calculated, the total sub- 
system weight must be used, not the half weight for the calculation on 
Form 2. From then on the calculation proceeds as before. 

Application 2 shows one of the many ways the Model can be expanded 
beyond the formal methodology which has been developed. 




'll 


00 



• ’T'V 







NON PROGRAM SPECIFIC SUBSYSTEM NCU ACQUISITION COSTS 


APPLICATION 2 


Form 1 


(D 


(D 


(D ® (D ® 


Parameter Des/Dev 
Value CER Value Fraction 


Des/Dev Number of 

Novelty Reduction Type Appr Des/Dev 
Factor Tests _ UCLCasi 


Symbol 

Source 


He 


Input 

NPS 


CER 


Input 



CD 

. (D 





Hardware 


Number of 

Learning 

Learning 

Test 

Unit Cost 

First 

Units 

Saving 

Curve Red 

NCU Cost- 

CFR Vai iiF- 

Unit, ..Cost. 

Produced 

Factor 

Factor 

.09 x® 

CER 

(Dx® 

Input 

Input 

, 

Table 4 

x®x® 






S ubsystem 
Struct 1 


1.0 


1.0 


Struct II 
Struct III 
Propul 
Guidance 
Att Ctrl 
Comm 

Data Hand 

Power 

Science 


JJL 


JUL 


JLiL 


JJL 


1.0 


1.0 


1.0 


1.0 


1.0 


1.0 


50 


17. B 


1.0 


1.0 


A8A.0 


316.3 


59 


JL 




.771 


1.0 


1.0 


1.0 


1.0 


1.0 


1.0 


NOTE! Use this calculation when the number of flight articles to be produced is 3 or more. 












Amortized 
Unit Acq 
NCU Cost 


+ (© X (sD) 

+ C(9) X @ 

X ©) 



CZIJ 

i 1 


1 


149.17 ]. 












‘S' 



PROGWfl SPKCli-IC SUBSYSTliH DESlGN/DflVELOPICNT NCU COSTS 


APPLICATION 2 


Form 2 


U9 



CD 

(D 

C!) 

(D 

CD 


CD 

CD 


pARAMifTiiR Value 

Des/Dev 
Clip. Value 

Novelty 

Fraction 

Qes/Dev 

Reduction 

Factor 

Number of 
Type Approval 
Tests 

Des/Dev 
NCU Cost 

Test NCU Cost 

Subsystem 
Des/Dev 
NCU Cost 

Symbol 

Source 

It^PUT 

CER 

Np 

Input 

f^D 

Table B-2 

Ht 

Table B-3 

.55 X ® X (2) 

.09 x(T) X (D 

® + ® 


Subsystem Name 
Structure 1 
Structure II 
Structure III 
Propulsion 
Guidance 

Attitude Control 
Communications 
Data Handling 
Power 
Science 

Subtotals 


PS 


^0. 




150 




50 


70 

50 


60 


0.8 


100 


[IPS 


50 




±J- 





11.2 


9.1 




785 


A3_ 


A. 


0 


JL 




1.0 




JJL 












JS_ 


M- 


lx£L 




JJL 


3 

93fi.5fi 

136.62 

. ?7?g8.. 

3 

1fl7.qq 

62.37 

170.3.6_ 

1 


1A1.75 

575^8 

1 


JLJQ 

31.23 

3 

s^a.qq 

.. 195.75 

53^.69 

3 

3RR.59 

211.68 

_3za^ 

l\ 


163.8 


U 

A17.5n 

27.0 JIO 

682.50 


172.70 

5B.52 

229,22. 



■'O. 



h 

RRfi.Sn 


755.3 


L298.52J 

U/Siwi 



Subsystem Design/Development NCU Cost (SSD/DC) 


SUBSYSTEB 



® @ 


Hardware 
Umit Cost 

Parameter Value CER Value 

Symbol 

Source Input CER 



Subsystem Name PS HPS 
Structure 1 200 ,25J< 

Structure 11 30 .R3 

o 

Structure 111 150 Jl 

Propulsion 50 .0309 

I . 

Guidance 50 .51 

Attitude Control 70 .56 


CoHMUNl cations 50 .57 

50 

Data Handling 60 1,93 

Power .8 107 

Science 100 .6H5 


Subtotals 

Subsystem hardware NCU cost (SSHWC) 





Hardware Unit Cost 

(i) X (?) Form 1 

PS HPS 

50.8 

12.9 

96.5 
1.595 

25.5 “ 
39.2 

28,50 ^ 

199,17 

85,8 

85.6 

69,5 “ 



COSTS 







APPLICATION 2 

Form 3 

© 

© 

© 

© 

© 

Hur^BER OF 
Test 

Articles 

Number of 
Flight 
Articles 

Subsystem 
Hardware 
HCU.Cost _ 

Flight Article 
Test Cost 

Hardviare 
KC li Cost 

% 

Table B-3 

”fa 

Input 

(( 9 ) +d)) X © 

.09 X .5 X (2-©) 
X C2-(D) 

©+® 



1 

3 

186 


611.25 

1 





3 

6.18 

.■.■23aI0_ 

29.28 






3 

3 

153 

. 195J5_ 

398.75 






3 

3 

235.2 

211.68 

996.88 






9 

3 

199.5 

122.85 

322.35 


3 

497.51 

122.85 

570.36 

9 

3 

600,6 

202.5 

8.05,10 






i 

3 

392.9 

169.56 

511.96 






9 

3 

951.5 

' 229.1 

675.60 








[3^009.09 ) 




[9.900.72! 
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E. Application 3 Planning Systems and sciences 

In this last application, the major, new and unique features of the 
model are utilized. Assume that four subsystems--gui dance, attitude 
control, communications, and data handling--are to be procured in a large 
enough quantity to qualify as a product ion- type or non-program specific 
purchase and that a significant number of pairs will be installed in the 
spacecraft. Consequently, the savings attributable to this "mass" pro- 
duction are computed by using the two-part Form 4. Form 4 is utilized 
after Forms 1, 2, and 3 have been completed. 

With Form 4, first fill out Part A which determines the total number 
of assembled spacecraft from all programs which will share the pairs of 
subsystems. This is a symmetrical array; therefore only one entry for 
each pair is made. For example, guidance and data handling are paired 
7 times (an input parameter from Table 3). 

Part B of Form 4 is used to translate the Commonality Interaction 
coefficients into remaining value parameters through the use of Tables B-5 
and B-6. 

For example. Structure I is paired with Structure II a total of three 
times. Using Table B-5, the number of pairs (3) and the 80% column yield 
a value of 0.95 which is entered in two places on Part B, the intersection 
of Structure I and Structure II, and the intersection of Structure II and 
I. As currently implemented, some interactions either never occur, or if 
they do, the interaction is negligible. These have been blanked out on 
Part A and set to unity on Part B. 

Part B is completed by entering the product of each row from Columns 1 
to 10 in Column 11, entering the appropriate values in Column 12 and com- 
pleting the Column 14 instructions. Totaling Column 14 provides the Ad- 
justed Subsystem Total NCU Cost (ASSTC). 

In Application 2, the Subsystem Total NCU Cost v/as utilized as the 
input parameter to determine the various program component elements. 
Application 2 did not utilize the saving for pair-wise commonality. To 
utilize the savings for pair-wise commonality, the Adjusted Subsystem 
Total NCU Cost is utilized as the input parameter. The appropriate values 
are then entered onto Form 5. 
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APPLICATION 3 


Fobh 1 



NON PROGfiAH SPECIFIC SUBSYSTEfI NCU ACQUISITION COSTS 



CD 


(D 


(D 

CD 





: Des/Dev 

Number of 



Paraheter 

Des/Dev 

Novelty 

Reduction 

Type Appr 

Des/Dev 


Value 

CCR Value 

Traction 

Factor 

^TfL5t_s 

ggjJCasL 

Symbol 



Np . 


Nr 


Source 

Input 

CER 

Input 

Table B-Z 

Table B-3 

.5 x(D 


NFS 





X0X0 

Subsystem 







Struct I 



1.0 

1.0 



Struct 11 



1.0 

1.0 



Struct H I 



1,0 

1,0 



pROpUL 



1,0 

1.0 



Guidance 

50 

1A,5 

1,0 ... 

1,0 

A 

39B.75 - 

Att Ctrl 

70 

11.2 

1.0 

1.0 

A 

A31.20 

Comm 

100 

9.1 

1.0' 

1.0 

A 

500.50 

Data Hand 

60 

12,5 

1.0 

1,0 

A 

A12.50 

Power 



1.0 

1.0 



Science 



1.0 

:1.0 



Note; Use this calculation when 

the number 

OF FLIGHT 

ARTICLES TO 

BE PRODUCED 



(D 



<01 

@ 

© 

Test 

NCIJ. Cost .. 

HARDVfARE 

Unit Cost 
CER Value 

First 
1Init_ Cost 

Number of 
Units 
Produced 

Learning 

Saving 

Factor 

Learning Amortized 
Curve Red Aco 
Factor 

,09 x0 
x(Dx® 

CER 


. Input 

Input 

Table A ■ 

CD +(t) 

*■ f® X (5)) 

M® X ® 

X ®) 







© 


. 





i 














r" .1 
















n n 

?Gi.nn 

_ ..51. . _ 

95.50 

in 

.85,.._ 

. .771 . 1 

r~9578A 1 

282. 2A 

. .56 

. 39.20 

....10 

.85 

.771 1 

rTl7723l 

327.60 

,57 

57.00 

'^5 

.80 

.663 1 

[j08 .20 } 

270.00 

1.43 

_§L3Q_ 


.90 

.801 1 

[I^<?.*Qi] 


I 1 

[Ull 


3 01! MORE. 



PROGRAn SPkXlFlC SUBSYS1H1 DESIGH/DEVELOPICNT HCU COSTS 


Symbol 

Sou«« 

Subsystem Name 
Structure I 
Structure !! 
StrulTure hi 
Propuls (OM 
Ruidauce 

Attitude Control 
Communications 
Data Handling 


(P 

Parameter Value 
I NPUT 

PS NFS 
m. 


30 


ISO 


50 


-50. 


70 


100 


60 


(P 


Des/Dev 
CEP. Value 


CER. 


2,53 

2,7 


10,5 


1,711 


1R.5 

11,2 


9.1 


1L5 


CP 


Input 


.5 




Oes/Oev 
Novelty Reduction 
Fraction Factor 


Table B-2 


.85 


.50 


.50 




Number of 
Type Approval 
Tssts 

Nt 

Table B-3 


CD 


Des/Oev 
NCU Cost 


.55 X Q X (D 

X® 


199.81 

37.87 


433.13 


23.53 


APPLICATION 3 

Test NCU Cost 


91.08 


21.87 


141.75 


7.70 


Form 


CD 


Subsystem 
Des/Dev 
NCU Cost 


.09 X® X ® (D + CD 
x(D 


285.89 



31.23 


Power . 

.8 

785 

0 

.5 

1 

172.70 

56.5?„ 

- 229.2? 

Science 

IDO 

8.3 

1.0 

1.0 

A 

456.50 

298.80 

755.30 

Subtotals 


— 




^1.318.54 

r 617.72 1 



Subsystem Desigh/Develophent NCU Cost CSSD/DC) 


G^36.26, 


7 ’■ 









_SYM»ax 

Source 


Subsystem Name 














w 

es? 




** 



SUBSYSTEH ftARDUARE COSTS 











APPLICATION 3 

1 

Q 

CD 

CD 

CD 

(D 




Parameter Value 

Hardware 
IJnit Cost 
CER Value 

Hardware Unit Cost 

Number of 
Test 

Articles 

Number of 
Flight 
Articles 

Subsystem 
Hardware 
NCU. Cost . 

Flight Article 
Test Cost 

Hardware 
NCU Cost 

Input 

CER 

(I) X d) Form 1 

^*TA 

Table B-3 

%A 

Input 

(® +(5)) X (D 

.09 X .5 X (2-(l)) 

(D+CD 


Form 


PS 


NPS 


PS 


NPS 


Subtotals 

Subsystem hardware NCU cost (SSHWC) 


12.641 .32 


LM- 


iL 













Structure II 

30 


.43 

12.90 


3 

3 

77.40 

21.87 

99,27 












Structure III 

150 


,31 

46,50. 


1 

3: 

186,00 

425,25 

611.25 












Propulsion 

50 


,0309 . 

. 1,545 


1 

3 

6,18 

23.10 

29,23 

• 











Guidance 













50 



95.84 


3 

287.52 

195,75 

483.27 

Attitude Control 








, 





70 



,117.23 


3' 

351.69 

211.68 

563,37 

COHHUN 1 CATIONS , 













inn 



108,20 


3 

_ . 32IL6D. 

„2il3...7£ 

- 57Q.-3Q- 

Data Handling 













fiO 



120.01 


3 

360.03 

-202,1 50- 

..-56ZJ3. 

Power 

.R 


107 

85.6(1 


1 

3 

342.40 

■ 163.56- 

-511.36. 












Science 

inn 


- -fiA5 

-£iL5.Q;. . 


4 

3 

451,50 

274.10 

, -675^60. 








= - .VI , Bi i i *■-' 














ro 

cr> 


ADJUSTED SUBSYSTEM fJCU COSTS 

Form A Part B 



(1). 

(D 

(D 


CD 

(D 

© 

® 


@ 







Str I 

Str ii 

Str III 

pROPUL 

Guidance Att Ctrl 

Comm 

Data Hd 

Power 

Science 

















Subsystem 

Interaction 

Product 

Subsystem 
Des/Dev 
m Cost 

Hardware 
NCU Cost 

Adjusted 

Subsystem NCU Cost 

Source 

Table B-6 









Row Prod 

2-® 

3-® 


+ © ) 

Str I 


.95: _ 


.9 





.9 


.76950 

285,83 

.39Q.,.62 . 


520.57 

Str M 

.95 





,95 

.95 


.95 

.9 

.73306 

59.74 

__ 99.27 


116.56 

Str III 
Propul 











1.0 

_579.,88 

611-25 .. 


1.186,. 13 

.9 , 




.87 ‘ 






.7830 

31,25 

73.2fi 


07.38 

Guidance 




.87 


.71 

,71 




.A38S7 


485,27 


21.1.95 

Att Ctrl 


.95 



,71 





,87 

.58682 


563.37 


J3iLGn 

Com 


.95 



.71 



.62 


.87 

,36383 


570.30 


^07.49 

Data }Id 







.W? 



.R7 



562.53 



Power 

.9 

.95 








.87 


©223.27 

511.96 


^1.33 

Science 


^ 




■ 87_ ■ 

.87 

.87 

_.87,. - 



.-75SJ.Q- 

675.60 


...737-79 



Adjusted subsystem- total NCU Cost (ASSTC) 


U^X3..23J 








:.■■■ t) 


■ ■■ ■> 
I I 
i 







F. Application Comparison Plonning Systems and Sciences 

In the three applications, various costs associated with either the 
hardware or program component cost were either determined directly from 
the CERs — program component cost— or determined through a process requir- 
ing the use of tite calculation forms. In this section, the completed 
Form 5 is presented with the appropriate entry for each component of the 
cost. In the lower portion of that form is an example of how comparisons 
can be expressed. As shown. Application 1 was considered to be the base 
line. The relative NCU cost between each of the remaining applications 
and the base- line are indicated. As expected, the use of increasing 
amounts of commonality significantly reduced the program NCU cost. 
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TOTAL PROGRAM NCU COSTS 


Form 5 


Program 

1 nCU Cost 

Source 

Application 1 

Application 2 

Application 3 

A. 

Hardware ConPONENi 









1. 

SSD/DC 

Form 2 

5.987.32 


A.3A3.61 


1.956.26 



2, 

SSHHC 

Form 3 

A^9AA.20 


A. 900. 72 





3. 

Total Hardware Component 



in.9;i.7? 


^2AA.33 


.6.A33.7 



ASSTC 

Form 4 | 

H/A ' 


N/A ' 

i 

A.213.23 


B. 

Program Level Component 









1. 

Program Management 

CER 

62Q..Q_ 


_33Q.Q 





2. 

Sys Analysis & Sys Ehgr 

CER 

1.000.0 


800 


360.0 



3. 

System Test 

CER 



. .760 


AAO.O 



A. 

Qual Assur s Reliability 

CER 

37.0 


...500 


295.0 



5, 

Assembly s Integration 

CER 

590 


500 


250. 0._ 




Operational Sup Equip 

CER 

70 


__S2 


160.0 



7. 

Total Program Level Comp 



■ 3.7IQ.QQ_ 

■■3. .192 


1.835.00 

C. 

Total Program NCU Cost CTPC) 



1A.6A1,72 


E^A36^ 


8.268,7 


iL 


Comparison Between Programs 

A, Baseline NCU 

Cost (BCj .77 

B. Percent Savings in Total Program or Project 
Cost Attributable to Commonality 



15 




Application A 


L 












Subs^tem Design & Oeveloprnent Cost-NCU/lb 



Subsystem Hardware Cost-NCU/lb 




Subsj^steJTi Design & Development Cost-NCU/lb 



Subsystem Hardware Cost-MCU/lb 






A-4. SUBSYSTEM CER: PROPULSION 


Type 

Hydrazi ne 


Thrust 
50 lbs 


D&D HW Cost 

NCU/lb-Th NCU/1 b-Th 

1.711 • .0309 


Monomethyl /hypazi ne 300 lbs 1.859 .0488 

+ Nitrogen Tetroxide 



• Use - Comments 


Flyby-mldcourse— slngl e chamber 
only 


Orbital injection and midcourse 
corrections— single chamber only 


bnning Systems and Sciences 


in Si Development Cost-NCU/lb 



Subsystem Hardv/are Cos 









Subsystem Design & Development Cost-NCU/lb 



Subsystenr Hardware Cost-NCli/lb 









Subsystem Hardware Cost-HCU/lb 


Subsystem Design & Development Cost-NCU/lb 



Subsystem Hardware Cost-NCU/lb 










t Cost-NCU/KVI 







Subsystem Design u Developnient Cost-NCU/lb 



Subsystem Hardware 
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APPENDIX a 


Novelty Fraction Assignment for Subsystem Design/Development 

Design/Development Reduction Factor as Function of Novelty 
Fraction 

Type Approval Testing Articles 
Production Learning Cost Reduction Factor 
Commonality Interaction Coefficient Level Selection 
Commonality Interaction. Coefficients 






Prior Design 
and Software 


Table B-1 

NOVELTY FRACTION ASSIGNMENT FOR S/S DESIGN & DEVELOPMENT (Np) 
Material and Fabrication Novelty 


Previously Used 
Materials and 
Fabrication 
Technology 


Minor Change in 
Materials 
Properties or 
in Fabrication 
Technology 


Significant 

Change 

in Materials or 
in Fabrication 
Technology 


Major Change in 
Fabrication 
or a Material 
with Little 
Experience in 
Spacecraft 
Usage 


Completely New 
Materials and 
Fabrication 
Technol ogv 


Minor Design 
or Software 
Changes 

Significant 
Changes to a 
Prior Design 
or Software 

Major Change 
to an Old 
Desi gn 


Completely 
New Design 
and Software 
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Struc III 3 3 2 2 1 

Propulsion 3 2,5 2 1.5 1 

Guidance 4 -3 3 2,5 2 

Attitude Control 43 3 2 1 

Communications 4 3 3 2.5 2 

Data Handling 4 3 3 2.5 2 

Power (elect) 3 2.5 2 1.5 1 

Science 4 3 3 2.5 1.5 


In Type Approval Testing each test requires that a prototype unit be made. 
Hence wTest - wArticles; = Nt - Mjft , None of the TA-Testing articles are 
used as Flight Articles; therefore, all of Flight Articles must be made 
separately after TA has been obtained. 
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Table B-4 

PRODUCTION LEARNING COST REDUCTION FACTOR (Fg) 

Cumulative Average Unit Cost 


Number 


Reducti on Factor 


of Units 

90% Curve 

85% Curve 

80% Curve 


mi 
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Tab! e B-5 

GOMMONALITY INTERACTION COEFFICIENT LEVEL SELECTION (IN PERCENT) 
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Subsystem Name 


1 

Structure I 


80 

70 





70 


2 

Structure II 

80 




80 

80 


80 

70 

3 

Structure III 










4 

Propul sTon 

70 



60 






5 

Gui dance 



60 


60 

70 




6 

Attitude Control 


80 


60 





60 

7 

Communications 


80 

1 

70 



60 


60 

8 

Data Handling 





- 

60 



60 

9 

Power (elect.) 

70 

80 







60 

10 

Science 


70 



60 

60 

60 

60 
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Number 

Common Pairs 


Table B-6 

COMMONALITY INTERACTION COEFFICIENTS ( ir..) 

I J 


80% Curve 70% Curve 

Coefficients Coefficients 


60% Curve 
Coefficients 




Program Management Cost»NCU 







rrn 
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EXHIBIT C-5. PROGRAM COMPONENTS: ASSEMBLY AND INTEGRATION 


Total Subsystem Cost-NCU 
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NON PROGRAM SPECIFIC SUBSYSTEM NCU ACQUISITION COSTS 


Form 1 



0) 

CD 

( T ' 




® 

® 

® 



® 



Parameter 

Value 

Des/Dev 
CER Value 

Novelty 

Fraction 

Des/Dev 

Reduction 

Factor 

Number of 
Type Appr 
Tests 

Des/Dev 
NCU Cost.. 

Test 

NCU Cost 

Hardware 
Unit Cost 

CER Value 

First 

Unit Cost 

Number of 
Units 
Produced 

Learning 

Saving 

Factor 

Learning 
Curve Red 
Factor_ 

Amortized 
Unit Acq 
NCU Cost 

Symbol 

Source 

Input 

NPS 

CER 

A 

Input 

Fd 

Table B-2 

Nt 

Table B-3 

.5 X® 
x®x® 

.09 X® 
x®x® 

CER 

®X® 

Input 

Input 

Table 9 

Cz) 

+ (® X ®) 

+ ((D X ® 

X ®) 


Subsystem 


Struct I 
Struct II 
Struct III 
Propul 
Guidance 
Att Ctrl 
Comm 

Data Hand 

Power 

Science 


® . 


Note: Use this calculation when the number of flight articles to be produced is 3 or more. 






PROGRAM SPECIFIC SUBSYSTEM DESIGN/DEVELOPHEKT HCO COSTS 



Form 2 


Symbol 

Source 

SUBSVSTEH Name 
Structure I 


(D 

CD 

(D 

Q 

(D 

CD 

CD 

® 

Parameter Value 

Des/Dev 
CER Value 

Novelty 

Fraction 

Des/Dev 

Reduction 

Factor 

Number of 
Type Approval 
Tests 

Des/Dev 
NCU Cost 

Test NCU Cost 

Subsystem 
Des/Dev 
NCU Cost 

Input 

CER 

% 

Input 

Pd 

Table B-2 

«T 

Table B-3 

.55 X ® X (D 

X® 

.09 x(T) X CD 

xd) 

® +® 


Structure 1 1 ' , 

Structure III - 

Propulsion ' 

Guidance - : 

Attitude Control ■ ; 

ComUNICATIOHS ____ 

Data Hahdlins ■ 

Power 

Science / ' ■ 

Subtotals 

SuBSYSTEn Besigh/Developheht NGU Cost (SSD/DC) 



SUBSYSTEM 





d) (2) @ 

Hardware 
Unit Cost 

Parameter Value CER Value Hardware Unit Co; 

■SY/m 

Source Input CER (D x (2) Form 1 


Subsystem Name PS NPS PS NPS 

Structure I 

Structure II 

Structure III 

Propulsion 

Guidance 

Attitude Control 

Communications 

Data Handling 

Power 

Science 


Subtotals 

Sllsystem hardware NCU cost (SSHWC) 




Form 3 



(D 

(D 

(2) 

(D 

Number of 
Test 

Articles . 

Number of 
Flight 
Articles 

Subsystem 
Hardware 
NCU Cost 

Flight Article 
Test Cost 

Hardware 
NCU Cost 

I'^TA 

Table B-3 

Input 

(® + (D) x(3) 

.09 X .5 X (2-(l)) 

(D+® 






































- »;=pi, _ . ^ T^- 


«p 






ADJUSTED SUBSYSTEM- NCU COSTS 


Form Part 





CD 


(D © 


® 


Qb) (2) 


© 



Str. L 

Str !! 

Str in 

Propul 

Guidance Att Ctrl 

Comm 

Data Hd 

Power 

Science 













Subsystem 

Interaction 

Product 

Subsystem 
Des/Dev 
NCU Cost 

Hardware 
NCU Cost 

Adjusted 

Subsystem NCU Cost 

Source 

Table B-6 







Row Prod 

2-® 

3-® 

(2)J< (® + vS> ) 


Str ! 


Sir II 

Str III 
Propul 

Guidance 


Att Ctrl 

Comm 

Data Hd 

Power 

Science 

Adjusted subsystem total NCU Cost (ASSTC) 











TOTAL PROGRAM NCU COSTS 


Source 


Application 1 


Application 2 


Application 3 


Application 4 


A, Hardware Component 


1. SSD/DC 


Form 2 


2. SSHWC 


Form 3 


Form 4 


3. Total Hardware Component 


B. Program Level Component 
1, Program Management 


2. Sys Analysis & Sys Engr CER 


3. System Test 


4. Qual Assur & Reliability CER 

5, Assembly S Integration CER 


6. Operational Sup Equip CER 


7, Total Program Level Comp 


C. Total Program NCU Cost (TPC) 


Comparison Between Programs 

A. Baseline NCU 

Cost (BC) 

B. Percent Savings in Total Program or Project 
Cost Attributable to Commonality 


(Kjptxioo) 











